**** BEGIN LOGGING AT Fri Apr 15 23:59:56 2005
Apr 16 00:11:22 <rwhitby-away> copperbeech: jp30 does
Apr 16 00:18:05 <copperbeech> ok - I think I have found out where the problem is coming from. I've installed the native toolchain and downloaded the CVS tree
Apr 16 00:18:40 <copperbeech> I'me done the make on directories etc and am now trying: make appweb
Apr 16 00:19:39 <copperbeech> I think the problem is that there is a "basic configuration variable" called BLD_CPU which is not set
Apr 16 00:19:47 <copperbeech> So I have 2 issues: 
Apr 16 00:20:37 <copperbeech> a) Where do I set this variable - info from http://www.mbedthis.com/products/appWeb/doc/source/building.html
Apr 16 00:21:01 <copperbeech> b) what should I set it to? It takes one of the following values:
Apr 16 00:21:14 <copperbeech> #define MPR_CPU_UNKNOWN0
Apr 16 00:21:14 <copperbeech> #define MPR_CPU_IX861
Apr 16 00:21:14 <copperbeech> #define MPR_CPU_PPC 2
Apr 16 00:21:14 <copperbeech> #define MPR_CPU_SPARC 3
Apr 16 00:21:14 <copperbeech> #define MPR_CPU_XSCALE 4
Apr 16 00:21:15 <copperbeech> #define MPR_CPU_ARM 5
Apr 16 00:21:28 <copperbeech> #define MPR_CPU_MIPS 6
Apr 16 00:22:01 <copperbeech> I think part of the problem is that it was previously compiled cross and I am trying to compile it native
Apr 16 00:22:37 <copperbeech> Is the NSLU2 processor ARM or XSCALE ?
Apr 16 00:23:26 <copperbeech> jp30, rwhitby: you got any tips on the above? Thanks.
Apr 16 00:23:26 <jacques> xscale, big-endian
Apr 16 00:23:50 <copperbeech> jacques: thanks - that's one down ;-)
Apr 16 00:24:02 <copperbeech> just got to work out how to pass this into configure now.
Apr 16 00:28:24 <jacques> oh, I'm starting to recall now
Apr 16 00:28:48 <jacques> I tried native compiling appweb, but the (*&^*%&( developers require some binaries in the configure process
Apr 16 00:29:19 <jacques> binaries which are not available in armeb flavor
Apr 16 00:36:12 <copperbeech> hmm any memories of what they are? is this a problem I'm going to hit downstream of these flags?
Apr 16 00:36:33 <jacques> I don't recall dealing with the flags issue
Apr 16 00:36:40 <jacques> but then I was trying to build it manually
Apr 16 00:37:41 <jacques> the binaries are bld, bldout, and maybe something else
Apr 16 00:37:57 <copperbeech> yes they definately use bld
Apr 16 00:37:59 <jacques> if you look in the appweb/bin dir you should see them
Apr 16 00:38:23 <rwhitby-away> what's the big attraction of appWeb over thttpd and/or apache?
Apr 16 00:41:43 <copperbeech> Well to be honest, it's just the one I have installed, and I have never tried thttpd. But it does seem to have a lot of functionality, such as virtual sites, SSL, user and group management, restricted directories and good documentation. It is trying to be an embedded apache.
Apr 16 01:11:45 <rwhitby-away> eno-away: jabber, nice :-)
Apr 16 01:12:51 <CIA-9> 03rwhitby * 10unslung/ (Makefile make/grep.mk): Changed $(TARGET) to $(UNSLUNG_TARGET), so it can be used on the command line for our automated builds without polluting the namespace.
Apr 16 01:19:28 <CIA-9> 03rwhitby * 10unslung/Makefile: Promoted grep for wl500g.
Apr 16 01:20:59 <rwhitby-away> jp30-work: as soon as I update the top-level Makefile on nudi, we will be immune from people checking in the wrong value for UNSLUNG_TARGET
Apr 16 01:22:57 <rwhitby-away> jp30-work: there is now a Makefile in /home/unslung on nudi which does everything (cvs up; make; make upload)
Apr 16 01:36:43 <copperbeech> OK - time to try the thttpd+php
Apr 16 03:58:36 <rwhitby-away> nslu.sf.net down for anyone else?
Apr 16 04:00:33 <[cc]smart> While trying to retrieve the URL: http://nslu.sf.net/ 
Apr 16 04:00:34 <[cc]smart> The following error was encountered: 
Apr 16 04:00:34 <[cc]smart>  Connection Failed
Apr 16 04:01:54 <rwhitby-away> Bummer.  This also affects ipkg.nslu2-linux.org :-(
Apr 16 04:02:08 <rwhitby-away> There goes my plan to test php tonight ...
Apr 16 04:03:24 <jacques> it does seem rather unresponsive
Apr 16 04:03:52 <rwhitby-away> I was right in the middle of a feed update too ....
Apr 16 04:39:58 <copperbeech> has anyone got the htpasswd files working with thttpd?
Apr 16 04:40:21 <rwhitby> dunno
Apr 16 04:40:26 <copperbeech> I can get them set up and created and the server asking for authentication, but the authentication never passes.
Apr 16 04:41:43 <copperbeech> The https / authentication aspects of thttpd are nowhere near as sophisticated as for appWeb... which is a good thing when it comes to setting it up, and a bad thing if you want to do anything more than basic authentication :-)
Apr 16 04:42:36 <copperbeech> rwhitby: I got the native toolchain set up but found out that part of the build scripts for appWeb require 2 i386 binaries... :-P
Apr 16 04:43:00 <copperbeech> nothing's ever simple is it!!
Apr 16 04:43:36 <CIA-9> 03rwhitby * 10unslung/make/git.mk: Added a dependency on grep.
Apr 16 04:48:17 <CIA-9> 03rwhitby * 10unslung/make/grep.mk: Now generates the control file.
Apr 16 04:48:55 <CIA-9> 03rwhitby * 10unslung/sources/grep/control: Removed generated control file
Apr 16 04:50:36 <copperbeech> jaques: I found the sources for appWeb bldout and genDepends in a folder called bootstrap in the sources!
Apr 16 04:52:21 <jacques> copperbeech, are you going to try to build them on the nslu2? that could be cool
Apr 16 04:53:25 <rwhitby> I thought appWeb already built cross.  What do we get extra from a native build?
Apr 16 04:53:44 <jacques> rwhitby, nslu.sf.net seems to be back
Apr 16 04:54:29 <rwhitby> jacques: thx
Apr 16 04:54:41 <jacques> hungry again - gonna go cook some swordfish
Apr 16 04:54:54 <jacques> BIAB
Apr 16 05:14:16 <CIA-9> 03rwhitby * 10unslung/sources/bind/prerm: Now cleans up K09named after itself.
Apr 16 06:23:45 <rwhitby> Hmm - proftpd installs stuff in /usr/share/.... - not good.
Apr 16 06:32:27 <rwhitby> as does vsftpd ...
Apr 16 06:40:31 <krod_laptop> you can change the install path...
Apr 16 06:40:36 <CIA-9> 03rwhitby * 10unslung/Makefile: Moved some wl500g packages to a NEEDS_FIXING variable.
Apr 16 07:03:43 <CIA-9> 03rwhitby * 10unslung/Makefile: Promoted php-apache.
Apr 16 07:04:14 <rwhitby> jp30-work: updating feed with php-apache now ....
Apr 16 07:06:30 <rwhitby> krod_laptop: the install path is already changed to /opt.  The .mk file is creating /usr/share/empty explicitly.  It should not (it should create /opt/share/empty or some other directory under /opt).
Apr 16 07:08:08 <rwhitby> actually it's only proftpd, vsftpd is fine.
Apr 16 07:13:01 <CIA-9> 03rwhitby * 10unslung/make/proftpd.mk: Removed the creation of /usr/share/empty. It is not kosher, and does not seem to be referenced by the code, documentation, configuration, or startup scripts.
Apr 16 07:13:47 <CIA-9> 03rwhitby * 10unslung/make/proftpd.mk: Bumped the ipk version.
Apr 16 07:15:30 <CIA-9> 03rwhitby * 10unslung/Makefile: Re-promoted proftpd and vsftpd for wl500g.
Apr 16 07:32:10 <ka6sox> morning
Apr 16 07:32:22 <rwhitby> g'day
Apr 16 07:32:44 <ka6sox> howdy....I see you have been a buzy bee
Apr 16 07:33:16 <rwhitby> did a test install of all the wl500g packages, to weed out those that compiled but didn't install properly.
Apr 16 07:34:04 <ka6sox> I'll bet that proved interesting.
Apr 16 07:34:27 <ka6sox> and I see all the wrong places things were trying to be installed in.
Apr 16 07:35:01 <rwhitby> Having /usr read-only on the wl500g is a good test ...
Apr 16 07:35:53 <ka6sox> probably not enough room for JFFS2 in only 4MB.
Apr 16 07:36:59 <rwhitby> right.  Oleg has a 64K flashfs area
Apr 16 07:44:32 <CIA-9> 03rwhitby * 10unslung/make/php.mk: Now sets EXTENSION_DIR explicitly, so that php-config reports the correct value.
Apr 16 07:45:22 <rwhitby> hey kergoth
Apr 16 07:45:30 <CIA-9> 03rwhitby * 10unslung/make/php-apache.mk: Now sets EXTENSION_DIR explicitly.
Apr 16 07:45:40 <rwhitby> kergoth: been following git development?
Apr 16 07:55:08 <ka6sox> rwhitby, are you still observing daylight "savings" time?
Apr 16 07:55:41 <rwhitby> nope, winter here.
Apr 16 07:55:58 <rwhitby> 12:25am
Apr 16 07:56:49 <ka6sox> ah..okay 7:55am here
Apr 16 07:58:54 <ka6sox> slugbugs are down and are getting closed/fixed.
Apr 16 07:59:26 <rwhitby> Hmm - my php build is missing the shared libraries for the extensions.
Apr 16 08:09:29 <rwhitby> *** Warning: libtool could not satisfy all declared inter-library
Apr 16 08:09:30 <rwhitby> *** dependencies of module xsl.  Therefore, libtool will create
Apr 16 08:09:30 <rwhitby> *** a static module, that should work as long as the dlopening
Apr 16 08:09:30 <rwhitby> *** application is linked with the -dlopen flag.
Apr 16 08:09:37 <rwhitby> Same for all the extensions
Apr 16 08:10:07 <rwhitby> ok, that's it for me.  Hopefully jp30 can push php and php-apache to the feed while I sleep.
Apr 16 08:15:55 <ka6sox> nitey
Apr 16 08:54:39 <krod_laptop> hm, i found a nslu2 on ebay for 9.99
Apr 16 08:54:50 <krod_laptop> shipping costs seem legit
Apr 16 08:54:59 <krod_laptop> 4d left..
Apr 16 09:45:32 <CIA-9> 03jp30 * 10unslung/make/xemacs.mk: xemacs: disable x11 support, as it does not work correctly right now
Apr 16 10:18:21 <jp30> caplink811, ping?
Apr 16 10:18:39 <caplink811> jp30: pong
Apr 16 10:19:35 <jp30> hi, caplink811: i was thinking it would be good to split the openldap package into openldap and openldap-libs (both generated by openldap.mk). thoughts?
Apr 16 10:20:03 <caplink811> np, if you would do so, pls
Apr 16 10:20:34 <jp30> ok, i'll just go ahead and do it. this should help make it possible to install apache w/o an ldap server
Apr 16 10:20:48 <caplink811> k, fine idea
Apr 16 11:29:19 <CIA-9> 03jp30 * 10unslung/ (make/openldap.mk sources/openldap/control): openldap: generate control, openldap-libs, bump ipk version
Apr 16 11:31:20 <CIA-9> 03jp30 * 10unslung/make/ (apr-util.mk apache.mk): apache: depend only on openldap-libs
Apr 16 12:45:21 <copperbeech> futher to the busybox bug - it seems to be happening in a makefile at a line which looks like:
Apr 16 12:45:56 <copperbeech> @echo "    rm -f $(CLEANIT)" | $(BLDOUT)
Apr 16 12:46:04 <copperbeech> which is expanding to:
Apr 16 12:46:56 <copperbeech> @echo "rm -f ./bldout.o ./getopt.o *.a *.o *.lo *.tmp *.bak core *.out *.map *.sym" | bldout
Apr 16 13:42:08 <ecopperbech> ok - have now built bldout manually from bldout.cpp and copied it over. 
Apr 16 13:42:37 <ecopperbech> it is now clear that the actual problem is that the makefile is looking for 'cc' to compile and not 'gcc'...
Apr 16 13:42:45 <ecopperbech> wonder where that is set...
Apr 16 13:48:00 <ecopperbech> ok - have bodged that one by making a symlink called 'cc' and pointing it to 'gcc'
Apr 16 13:49:03 <ecopperbech> next problem is that some files being created by the make scripts are with permissions -r--r--r-- and then there is a failure as 'touch' has not got permission... 
Apr 16 13:49:38 <ecopperbech> is there a place where permissions are defaulted when new files are created?
Apr 16 14:02:50 <ecopperbech> OK - you'll all be glad to hear I've had it for today... tired and time for sleep. Enjoyed the fun and voyage of discovery. Perhaps I should have started this lark with something easier than appWeb!
Apr 16 14:03:04 <ecopperbech> night all.
Apr 16 14:52:19 <rwhitby-asleep> In file included from gdkdrawable-x11.c:31:
Apr 16 14:52:19 <rwhitby-asleep> ../../gdk/gdkregion-generic.h:157: error: redefinition of `struct _POINTBLOCK'
Apr 16 14:52:19 <rwhitby-asleep> ../../gdk/gdkregion-generic.h:160: error: redefinition of `POINTBLOCK'
Apr 16 14:52:19 <rwhitby-asleep> . /home/unslung/packages/staging/opt/include/X11/region.h:186: error: `POINTBLOCK' previously declared here
Apr 16 14:52:20 <rwhitby-asleep> make[5]: *** [gdkdrawable-x11.lo] Error 1
Apr 16 14:52:34 <rwhitby-asleep> jp30-work: ever see that before?
Apr 16 16:26:49 <eno> anyone here?
Apr 16 17:07:26 <ka6sox-away> sorta eno...
Apr 16 17:12:47 <eno> hi ka6sox!
Apr 16 17:13:24 <ka6sox-away> hi eno...hows it going.
Apr 16 17:14:18 <eno> i'm using 3.18b right now, i looked the wiki pages, but cannot find anywhere stating the major diff between 3.x and 4.x
Apr 16 17:15:00 <eno> what's the advantage of going 4.x?
Apr 16 17:15:03 <ka6sox-away> that is a good question.
Apr 16 17:15:18 <eno> especially from end user's point of view
Apr 16 17:15:52 <eno> i saw the other day in the irc log that we need more alpha testers for 4.x
Apr 16 17:16:07 <ka6sox-away> yes we do.
Apr 16 17:16:56 <eno> i'm usually pretty conservative, esp. since i only have 1 slug to play with right now and it's working pretty fine
Apr 16 17:17:13 <eno> that's why i'm asking the question
Apr 16 17:18:00 <ka6sox-away> I'm going to ping the release manager to answer that question and then i'll get a wikipage up for that.
Apr 16 17:19:13 <eno> that would be really helpful, for getting more testers for 4.x
Apr 16 17:21:40 <eno> i got my distcc working with cross compilation the other day
Apr 16 17:25:11 <ka6sox-away> that sounds good...i would like to see us do it for Native builds as it takes soooo long to do builds natively
Apr 16 17:25:41 <eno> exactly
Apr 16 17:26:39 <ka6sox-away> actually what I'd like is the setiathome verson of distcc so that we can harvest the power of these slugs that are sitting idle most of the time.
Apr 16 17:27:15 <Tiersten> On a 133/266MHz SA?
Apr 16 17:27:23 <Tiersten> It'd probably take a month to do one WU
Apr 16 17:28:06 <ka6sox-away> no no no...I mean using the slugs to do distcc and send their results back to the main slug.
Apr 16 17:28:35 <Tiersten> ahh
Apr 16 17:28:48 <Tiersten> thought you wanted to run setiathome on the NSLU2!
Apr 16 17:28:51 <ka6sox-away> so like 20 slugs can do the make/config/cc1 and then send the results back for linking.
Apr 16 17:29:14 <eno> hmm, interesting idea
Apr 16 17:29:35 <Tiersten> bbiab
Apr 16 17:29:45 <ka6sox-away> k
Apr 16 17:30:33 <ka6sox-away> if the slugs could download the source (on their own) and then compile and send every thing back for the linking phase (can't see how to do that distributed)
Apr 16 17:32:50 <eno> there needs to be some kind of registration service for the central slug to find the other slugs
Apr 16 17:34:31 <eno> as far as the central slug is concerned, the other peers can be real slug, or cross compilers
Apr 16 17:35:15 <ka6sox-away> yeah.
Apr 16 17:35:30 <ka6sox-away> I was mostly thinking for Native-Only builds.
Apr 16 17:35:41 <ka6sox-away> we can throw a lot of horsepower at Crossbuilds
Apr 16 17:35:48 <ka6sox-away> but the slug is the slug.
Apr 16 17:36:00 <ka6sox-away> and for native builds its just very slow.
Apr 16 17:36:59 <eno> right, painfully slow
Apr 16 17:37:19 <jacques> and I *still* wanna know why it shows half the bogomips it should
Apr 16 17:38:14 <ka6sox-away> dyoung and I looked at that a little bit.
Apr 16 17:38:20 <eno> is the CPU crippled or something? is there a way to make it run 266MHz?
Apr 16 17:38:41 <ka6sox-away> there is no mode for reducing the core to 133mhz with the stepping that we have that is documented
Apr 16 17:38:55 <ka6sox-away> we need to look at the register that is conrolling corefreq.
Apr 16 17:39:38 <jacques> good afternoon, jbowler 
Apr 16 17:39:44 <ka6sox-away> hi jbowler 
Apr 16 17:40:13 <ka6sox-away> I suspect that the answer will be found in RedBoot.
Apr 16 17:40:22 <ka6sox-away> in the HAL code.
Apr 16 17:40:33 <jbowler> good <various> ;-)
Apr 16 17:40:49 <eno> so OE will be the answer?
Apr 16 17:41:28 <ka6sox-away> maybe APEX will be the answer
Apr 16 17:41:40 <jacques> hmmm, interesting theory
Apr 16 17:42:04 <jacques> [g2] is already using APEX on his slug
Apr 16 17:42:35 <ka6sox-away> we should ask him what his bogomips number is.
Apr 16 17:43:13 <jacques> yeah, definitely
Apr 16 17:45:58 <jacques> and we should also talk to beewoolie (sp?)
Apr 16 17:49:04 <Tiersten> back
Apr 16 17:49:43 <jbowler> Ah you all still seeing the bogus bogomips number?
Apr 16 17:53:32 <ka6sox-away> yeah
Apr 16 17:53:39 <ka6sox-away> dunno what that is all about.
Apr 16 17:54:02 <ka6sox-away> since the multiplier *should* be fixed in this stepping of the part.
Apr 16 17:55:03 <ka6sox-away> maybe somebody could write a little proggy that would verify whether we are running at 133mhz or 266mhz.
Apr 16 17:55:44 <jbowler> The guy you posted the original query had actually done that - and it looked correct (and it looked like 133MHz)
Apr 16 17:56:49 <ka6sox-away> so that would suggest that there is a corefreq mode that is *not* documented
Apr 16 17:56:54 <Tiersten> The bogomips value indicates that it is 133 still
Apr 16 17:57:12 <jbowler> Is there some way of getting the value out of /proc (cpu info?)?  I can't see  it on my current openslug builds 'cause by the time I can ssh in it's disappear off the top of the buffer.
Apr 16 17:57:26 <ka6sox-away> dmesg?
Apr 16 17:58:22 <Tiersten> I'm inclined to believe the bogomips value since they don't usually change the algorithm
Apr 16 17:58:33 <ka6sox-away> [tking@gastro tking]$ cat /proc/cpuinfo
Apr 16 17:58:33 <ka6sox-away> Processor       : XScale-IXP425/IXC1100 rev 1 (v5b)
Apr 16 17:58:33 <ka6sox-away> BogoMIPS        : 131.48
Apr 16 17:58:33 <ka6sox-away> Features        : swp half thumb fastmult edsp 
Apr 16 17:58:33 <ka6sox-away> Hardware        : Intel IXDP425 Development Platform
Apr 16 17:58:34 <ka6sox-away> Revision        : 0000
Apr 16 17:58:36 <ka6sox-away> Serial          : 0000000000000000
Apr 16 17:59:12 <jbowler> It's per-arch, the code to calculate it is ARM assembler and makes some assumptions (implicitly) about the function entry etc.
Apr 16 17:59:25 <Tiersten> Yeah but as I said, it doesn't change often
Apr 16 17:59:42 <Tiersten> You can usually use it to compare relative speeds if you're using the same CPU family and revision
Apr 16 17:59:52 <ka6sox-away> which suggests (as I think we already know) that they just simply took the IXDP montevista code and just *used* it.
Apr 16 18:00:05 <Tiersten> So comparing a P3 to a P4 wouldn't work but between a Northwood P4 and a Northwood P4 it should work
Apr 16 18:00:34 <jacques> cat /proc/cpuinfo
Apr 16 18:00:37 <jacques> it should be there
Apr 16 18:00:52 <ka6sox-away> thats what I just showed from Gastro.
Apr 16 18:01:13 <Tiersten> Didn't somebody get a 266ish value for bogomips?
Apr 16 18:01:20 <jacques> ah OK, I thought you had gotten that from dmesg
Apr 16 18:01:21 <Tiersten> I seem to remember somebody getting that
Apr 16 18:01:44 <ka6sox-away> does somebody have a cpuinfo from a OpenSlug  box?
Apr 16 18:01:51 <jacques> it's the same
Apr 16 18:02:14 <ka6sox-away> it *should* be set in the Bootloader
Apr 16 18:02:41 <ka6sox-away> but according to the doco there is no *underclocked* mode for this stepping of the part.
Apr 16 18:02:56 <jacques> Processor       : XScale-IXP42x Family rev 1 (v5b)
Apr 16 18:02:56 <jacques> BogoMIPS        : 133.12
Apr 16 18:03:00 <jacques> that's from openslug
Apr 16 18:03:02 <ka6sox-away> so its an undocumented *feature*
Apr 16 18:03:12 <Tiersten> Unless they're doing something daft like dividing the crystal output
Apr 16 18:03:19 <Tiersten> But that'd really screw up the PCI timing
Apr 16 18:03:29 <ka6sox-away> different clock
Apr 16 18:03:41 <ka6sox-away> it would mess with the memory timing.
Apr 16 18:03:43 <Tiersten> Doesn't it generate it all from one?
Apr 16 18:03:53 <ka6sox-away> there are 4 clocks in the slug
Apr 16 18:03:55 <Tiersten> You only need to give it 33MHz or something
Apr 16 18:04:00 <Tiersten> Hrmm
Apr 16 18:04:07 <Tiersten> What was I looking at then in the datasheet...
Apr 16 18:05:16 <jbowler> I got 266.24 - and I still do!
Apr 16 18:05:33 <jacques> ??
Apr 16 18:05:37 <ka6sox-away> jbowler, ????
Apr 16 18:05:43 <jbowler> Here's /proc/cpuinfo:
Apr 16 18:05:43 <Tiersten> jbowler: Okay.  It was you then :)
Apr 16 18:05:59 <jbowler> Um, ok, want me to send all 25 lines?
Apr 16 18:06:09 <ka6sox-away> go to #flood
Apr 16 18:06:22 <jacques> or just first three and last three
Apr 16 18:06:27 <Tiersten> A XScale core should give roughly 1 bogoMIP per MHz
Apr 16 18:07:31 <ka6sox-away> agreed
Apr 16 18:07:32 <jacques> jbowler, what kernel version?
Apr 16 18:07:49 <jacques> and did you do any special configuration?  I assume you haven't changed the bootloader?
Apr 16 18:08:19 <jbowler> jacques: eh, yes - that's 'jonslug' not 'openslug' - 2.6.11-mm4
Apr 16 18:08:51 <jbowler> No RedBoot change, the info was obtained from within 'bootbox' - which is a shrunken 'switchbox'
Apr 16 18:09:08 <jbowler> I'm reflashing openslug now.
Apr 16 18:09:11 <Tiersten> any kernel changes?
Apr 16 18:09:17 <jacques> we need some sort of tiny app that we can run on both slugs to prove once and for all that they are running at different speeds
Apr 16 18:10:07 <Tiersten> just running dhrystone on it and timing it would be enough
Apr 16 18:10:09 <jbowler> Oh, I've built -march=xscale -mtune=xscale
Apr 16 18:10:29 <Tiersten> Same otherwise?
Apr 16 18:10:50 <jacques> well it *is* a different kernel version than regular openslug isn't it?
Apr 16 18:11:04 <ka6sox-away> I though ours was 2.6.11
Apr 16 18:11:23 <jbowler> There are a lot of ARM patches in MM
Apr 16 18:11:24 <jacques> not -mm4 tho
Apr 16 18:11:30 <Tiersten> hrmm
Apr 16 18:11:53 <Tiersten> somebody needs to add mm4 to a stock openslug kernel and see if it changes
Apr 16 18:11:58 <Tiersten> and do the dhrystone benchmark
Apr 16 18:12:01 <jacques> jbowler, I don't suppose you added -mm4 to oe ?  :-)
Apr 16 18:12:23 <ka6sox-away> jbowler...If you feel comfortable with this I would like to know if there is a noticable difference in heat generated.
Apr 16 18:12:32 <jbowler> jacques: no, it's sitting on a branch.  I was thinking of adding 'nslu2-kernel' to OE for testing new kernels
Apr 16 18:13:07 <jbowler> kas6sox-away: ?  I have to put it somewhere painful to work this out?
Apr 16 18:13:18 <jacques> jbowler, you mean as a configuration variable ?
Apr 16 18:13:28 <jacques> heh
Apr 16 18:13:48 <jbowler> jacques: virtual/kernel (i.e. do distro=openslug but override the kernel pref.)
Apr 16 18:13:50 <ka6sox-away> just take it out of its case so that you can put your fingert on the processor.
Apr 16 18:14:11 <jacques> jbowler, sounds good to me
Apr 16 18:14:16 <ka6sox-away> at one time I heard that if we "messed" with the timing that we would cause catastrophic failure.
Apr 16 18:14:27 <jacques> ka6sox-away, or better yet, a temperature probe?  :-D
Apr 16 18:14:34 <ka6sox-away> yeah
Apr 16 18:14:36 <Tiersten> If it goes sssssssssssszzzzttt and you smell something cooking then take your finger off okay? :)
Apr 16 18:14:48 <ka6sox-away> lol
Apr 16 18:15:08 <Tiersten> It doesn't get that hot anyway
Apr 16 18:15:14 <ka6sox-away> not the stock one.
Apr 16 18:15:15 <jacques> for all we know, jbowler has an ir temperature gun
Apr 16 18:15:17 <jbowler> I've got a thermocouple and DMM somewhere, also I did chemistry so I know how to fry my fingers.
Apr 16 18:15:46 <ka6sox-away> this is good.
Apr 16 18:15:46 <Tiersten> You did chemistry?  Then the chemical burns on the fingertips should protect you ;)
Apr 16 18:16:11 <jbowler> tiersten: exactly ;-)
Apr 16 18:16:28 <jbowler> Ok, here's openslug (actually a uClibC build), same slug:
Apr 16 18:16:36 <jbowler> Processor       : XScale-IXP42x Family rev 1 (v5b)
Apr 16 18:16:36 <jbowler> BogoMIPS        : 133.12
Apr 16 18:16:37 <jbowler> Features        : swp half thumb fastmult edsp
Apr 16 18:16:42 <jacques> yes!
Apr 16 18:16:47 <jbowler> Hardware        : Linksys NSLU2
Apr 16 18:16:48 <jbowler> Revision        : 0000
Apr 16 18:16:48 <jbowler> Serial          : 0000000000000000
Apr 16 18:16:53 <jacques> we've got to be onto something here
Apr 16 18:17:07 <jacques> tho I hope it's not just a bogomips reporting bug :-D
Apr 16 18:17:11 <jbowler> I'll put the whole thing in #flood, might be something else different there.
Apr 16 18:17:26 <Tiersten> hmm interesting
Apr 16 18:17:35 <jacques> jbowler, no, everything other than bogomips was same as my 2.6.9 openslug last time
Apr 16 18:18:34 <Tiersten> There are some seriously bored people if they actually hang around in #flood
Apr 16 18:18:41 <Tiersten> ka6sox: you missed it
Apr 16 18:18:58 <ka6sox-away> rats
Apr 16 18:19:11 <jbowler> When I build jonslug apps I build -mthumb-interwork, when I build the kernel I have sometimes accidentally done the same thing.   At present I believe my build is 'right' - no thumb interwork support in the kernel.
Apr 16 18:19:35 <jbowler> ka6sox-away: shall I send again, the guys in there seemed very interested...
Apr 16 18:19:37 <Tiersten> that shouldn't affect it unless it really is breaking the calculation
Apr 16 18:19:45 <Tiersten> looks okay to me
Apr 16 18:19:46 <ka6sox-away> jbowler, please
Apr 16 18:20:39 <Tiersten> wonder what it is in mm4
Apr 16 18:21:15 <jbowler> I'm just looking, the patch is 686225 lines
Apr 16 18:21:19 <Tiersten> uh.  ka6sox-away.  Over here...
Apr 16 18:21:25 <ka6sox-away> I"m here
Apr 16 18:21:35 <Tiersten> i mean don't talk in #flood :)
Apr 16 18:21:44 <ka6sox-away> eno came over there.
Apr 16 18:21:48 <ka6sox-away> he started this...!
Apr 16 18:21:59 <ka6sox-away> (and for that I am grateful)
Apr 16 18:22:07 <Tiersten> yeah but people, could we please coordinate here and all join the channel at the same time :)
Apr 16 18:22:11 <jbowler> Look here: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11-mm4/
Apr 16 18:22:15 <Tiersten> we don't want to have to ask jbowler to paste it again :)
Apr 16 18:22:22 <ka6sox-away> true
Apr 16 18:22:47 <Tiersten> I'll download the broken out patch and have a look
Apr 16 18:22:52 <jacques> I'd love to find the one or two lines that makes the difference in that patch
Apr 16 18:23:04 <jacques> well, rather for someone like Tiersten to find it :-D
Apr 16 18:23:32 <Tiersten> heh
Apr 16 18:23:33 <Tiersten> :p
Apr 16 18:23:54 <ka6sox-away> how big is the Diff?
Apr 16 18:24:04 <jacques> this makes me happy - either way, this has been bugging me for a long time and I think it's soon to be resolved
Apr 16 18:24:08 <Tiersten> download the broken out one so you don't need to split the patch
Apr 16 18:24:28 <ka6sox-away> its broken out by arch?
Apr 16 18:24:44 <Tiersten> by individual patch
Apr 16 18:24:51 <ka6sox-away> k
Apr 16 18:25:21 <jbowler> broken_out in the link I sent, then probably bk-arm.patch
Apr 16 18:25:23 <ka6sox-away> its probably in some HAL stuff somewhere.
Apr 16 18:27:04 <jbowler> I should put the mm3 kernel into OE - then it will be there without any of my additional changes (e.g. the ones to the GCC config)
Apr 16 18:27:18 <jbowler> s/mm3/mm4/, or maybe 2.6.12-rc2-mm?
Apr 16 18:29:08 <ka6sox-away> well if it solves the problem of sluggish slugs then its a winner.
Apr 16 18:29:59 <jacques> I see nothing in bk-arm.patch - how about bk-cpufreq.patch ?
Apr 16 18:30:31 <ka6sox-away> its corefreq that is the difference I think
Apr 16 18:30:43 <ka6sox-away> and probalby will be in teh cpufreq.patch
Apr 16 18:33:19 <jacques> hmm, seems like lots of x86 stuff in that one
Apr 16 18:34:00 <Tiersten> Doubt it's the cpufreq one
Apr 16 18:34:08 <Tiersten> I didn't think we even had that enabled?
Apr 16 18:34:23 <Tiersten> The cpufreq patch just looks like it's tidying up some code
Apr 16 18:35:59 <jacques> some ixp stuff in the linus.patch
Apr 16 18:36:18 <jacques> rather a lot
Apr 16 18:36:43 <jacques> `course it *would* be the huge patch
Apr 16 18:36:51 <jacques> 472455 linus.patch
Apr 16 18:36:56 <ka6sox-away> is the linus patch an aggregation of submitted patches?
Apr 16 18:37:26 <jacques> I don't know
Apr 16 18:37:46 <jacques> yeah looks that way
Apr 16 18:37:52 <jacques> from reading the first part
Apr 16 18:41:19 <jacques> the only occurrences of "ixp4" are in bk-watchdog.patch and linus.patch
Apr 16 18:43:42 <ka6sox-away> okay so these patches *could* be in 2.6.12
Apr 16 18:43:43 <jbowler> The code which calculates the value is in arch/arm/lib/delay.S
Apr 16 18:44:15 <jbowler> And that code has not changed...
Apr 16 18:44:58 <jacques> jbowler, good to know
Apr 16 18:45:57 <jbowler> The linux (common) code which calculates BogoMIPS does a binary approximation based on the results of the __delay (I think) call - i.e. it does a bitwise approximation to get the final result.
Apr 16 18:46:27 <jbowler> Assuming it calls __delay it only executes two instructions in the loop - subs and bhi.
Apr 16 18:47:22 <Tiersten> Making it tune for xscale is affecting the delay loop??
Apr 16 18:47:52 <jacques> :-\
Apr 16 18:48:29 <Tiersten> not exactly reliable is it this calc :)
Apr 16 18:48:30 <jbowler> I don't think so - it must be somewhere else - the GCC tune does not affect assembler
Apr 16 18:49:00 <jbowler> Tiersten: I believe it is because the loop count passed in ends up so large.
Apr 16 18:49:22 <Tiersten> large?
Apr 16 18:49:41 <Tiersten> what do you mean?
Apr 16 18:50:09 <jbowler> Hmmm...  I can't find the code - when I checked it was doing _delay(foo) until that was sufficient for a clock tick to elapse
Apr 16 18:50:26 <Tiersten> wasn't that a bug ages ago?
Apr 16 18:50:34 <Tiersten> it was spinning for 30+ seconds
Apr 16 18:50:59 <Tiersten> From a quick look through, I can't find anything specific
Apr 16 18:51:07 <jbowler> I think there was a comment about that in there.
Apr 16 18:54:19 <Tiersten> I mean looking through mm4
Apr 16 18:54:43 <Tiersten> Most of the ARM patches are for adding a new arch s3c2410
Apr 16 18:54:49 <Tiersten> some stuff on watchdogs
Apr 16 18:55:10 <Tiersten> some stuff on IPC
Apr 16 18:55:11 <Tiersten> and that's really it for ARM specific stuff
Apr 16 18:56:27 <jacques> jbowler, can you get some Dhrystone numbers?  http://zoularis-macosx.sourceforge.jp/packages/20020307_10.1.3/packages/All/dhrystone-2.1.tgz
Apr 16 18:56:49 <jacques> i tried to find a better source but most are dead
Apr 16 18:57:35 <jacques> that's the same code as was used for this: http://www.nslu2-linux.org/wiki/Info/Performance  at the bottom: Dhrystone 2.1:Microseconds for one run through Dhrystone: 6.4 Dhrystones per Second: 155440.4 VAX MIPS rating = 88.469
Apr 16 18:58:39 <Tiersten> if it just turns out to be a bad bogomips calculation and there really isn't any difference between the two then we might see different numbers anyway because bogomips is used in timing loops all over the place
Apr 16 18:58:59 <Tiersten> so a diff might not be significant unless it is roughly double for jbowler's nslu2
Apr 16 18:59:05 <jbowler> jacques: This will be tricky, 'jonslug' is broken 'cause I tried to switch it to glibc, if the dhrystone works with autoreconf I can probably get it over to bootbox...
Apr 16 18:59:33 <ka6sox-away> its uClibc based now?
Apr 16 18:59:38 <Tiersten> It probably only needs the stdio functions
Apr 16 19:00:10 <Tiersten> jacques: that tar file is useless
Apr 16 19:00:15 <Tiersten> it's got a compiled copy in it
Apr 16 19:00:28 <Tiersten> lemme see if I can find my copy of the dhrystone source
Apr 16 19:01:26 <jacques> d`oh
Apr 16 19:01:45 <Tiersten> There is http://huron.cs.ucdavis.edu/academic/ecs250a.f97/benchmarks/synthetic/dhrystone.c but its very old
Apr 16 19:01:53 <jacques> i really want 2.1
Apr 16 19:01:56 <jbowler> ka6sox-away: yes, but I used a uClibC openslug too...
Apr 16 19:01:58 <Tiersten> ah
Apr 16 19:02:01 <jacques> to compare against that's already on the wiki
Apr 16 19:03:18 <jacques> why are these benchmarks alwaysso damn hard to find
Apr 16 19:03:21 <Tiersten> http://www.opensource.apple.com/darwinsource/10.3/gccfast-1614/gcc/testsuite/gcc.misc-tests/
Apr 16 19:03:27 <Tiersten> dhry.[ch]
Apr 16 19:03:36 <Tiersten> v2.1
Apr 16 19:03:41 <jacques> thanks
Apr 16 19:03:54 <jacques> why isn't there a tarball of the source anywhere findable??
Apr 16 19:03:57 <Tiersten> dunno
Apr 16 19:04:10 <jacques> I've been googling this for 10 minutes
Apr 16 19:05:28 <Tiersten> http://ftp.tu-clausthal.de/pub/netbsd/packages/1.6.2/evbppc/benchmarks/dhrystone-2.1.tgz
Apr 16 19:05:33 <Tiersten> Your google-fu is lacking I'm afraid :)
Apr 16 19:06:13 <jacques> also no source
Apr 16 19:06:18 <Tiersten> doh
Apr 16 19:06:31 <Tiersten> okay.  my actually-looking-in-the-file-fu is even more lacking
Apr 16 19:06:42 <jacques> and looks like I need to modify the source
Apr 16 19:06:43 <jacques> because
Apr 16 19:06:57 <jacques> dhry.c:31: error: conflicting types for 'malloc'
Apr 16 19:08:16 <Tiersten> hmm
Apr 16 19:08:40 <jacques> i wish the guy who posted on the wiki had listed his sources
Apr 16 19:08:42 <Tiersten> change the char to a void
Apr 16 19:08:44 <Tiersten> yeah
Apr 16 19:09:14 <Tiersten> uh
Apr 16 19:09:20 <Tiersten> that copyt has been hacked up really badly
Apr 16 19:09:28 <jacques> ok it compiles but does nothing
Apr 16 19:09:32 <Tiersten> all the printfs have been commented out!
Apr 16 19:09:50 <jacques> ok, starting over
Apr 16 19:10:45 <jbowler> Yes, same problem here...  Where's the original source!
Apr 16 19:11:56 <jacques> extremely annoying this is
Apr 16 19:11:59 <Tiersten> gah
Apr 16 19:12:15 <jacques> I did find this: http://www.arm.com/pdfs/Dhrystone.pdf which I might read later
Apr 16 19:12:59 <ka6sox-away> Spelunking for Code
Apr 16 19:14:31 <ka6sox-away> http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MC68901-ARCHIVED&nodeId=01z3Tw9059gCFz
Apr 16 19:15:14 <ka6sox-away> it seems to be there.
Apr 16 19:15:36 <ka6sox-away> is that what you are looking for?
Apr 16 19:15:53 <Tiersten> looks like it
Apr 16 19:15:57 <Tiersten> need to test it first
Apr 16 19:17:51 <Tiersten> argh
Apr 16 19:17:54 <Tiersten> that doesn't print out anything either!
Apr 16 19:18:01 <Tiersten> FFS...
Apr 16 19:18:06 <Tiersten> Can we just use dhrystone 1?
Apr 16 19:18:59 <jbowler> Eh, I just wrote a program.  It reads "25" on openslug (that's 25 seconds +/- 1)
Apr 16 19:19:25 <Tiersten> It lists dhrystone 1 and 2 on the performance page anyway
Apr 16 19:19:32 <Tiersten> program?
Apr 16 19:20:07 <jbowler> loop 1000000 or so times calling a volatile function
Apr 16 19:20:12 <Tiersten> ah
Apr 16 19:21:26 <jbowler> reflashing...  Then I'll netcat the program into bootbox and run it from there - same program, so a guaranteed valid test...
Apr 16 19:22:07 <jacques> ok cool
Apr 16 19:26:48 <jacques> what I'd really like to see are lmbench results
Apr 16 19:27:10 <jacques> but that's after we know if there's really a speed difference
Apr 16 19:27:37 <jbowler> I had to relink -static, but I get 25 still.
Apr 16 19:28:00 <jbowler> I.e. absolutely no difference - it's just a calculation error somewhere.
Apr 16 19:28:40 <Tiersten> hmm
Apr 16 19:29:12 <Tiersten> they must be clocking it slow then
Apr 16 19:29:40 <Tiersten> we really need a IXDP425 board to test it with...
Apr 16 19:30:07 <ka6sox-away> no dsaxena
Apr 16 19:30:14 <jacques> [g2]
Apr 16 19:30:22 <jacques> when he's around
Apr 16 19:30:25 <ka6sox-away> therer ya go
Apr 16 19:30:49 <ka6sox-away> jbowler: can you post that code?
Apr 16 19:31:43 <jbowler> #include <time.h>
Apr 16 19:31:43 <jbowler> #include <stdio.h>
Apr 16 19:31:43 <Tiersten> slap a similar kernel on the IXDP425 which we know the speed of and see what value we get
Apr 16 19:31:44 <jbowler> volatile int fooey(void) { return 22; }
Apr 16 19:31:44 <jbowler> int main(void) { int i; time_t t0 = time(0), t1;
Apr 16 19:31:44 <jbowler>     for (i=0; i<100000000; ++i) fooey(); t1 = time(0);
Apr 16 19:31:45 <jbowler>     printf("%d\n", t1 - t0); return 0; }
Apr 16 19:32:32 <Tiersten> if we put something similar to what jbowler has and we also get a larger value then it's proven to be a calculation error somewhere
Apr 16 19:32:39 <Tiersten> if we don't then well... dunno :)
Apr 16 19:33:24 <ka6sox-away> okay so what we need is for [g2] to use the same code as jbowler and run the test on his IXDP board.
Apr 16 19:33:29 <jbowler> The assembler of that code shows that it does hit the data cache.  The loop of the test code is I-cache only (subs, bhi)
Apr 16 19:36:54 <jacques> that's neat - how do you do bold ?
Apr 16 19:37:10 <Tiersten> bold?  as in IRC?
Apr 16 19:37:13 <jacques> yeah
Apr 16 19:37:14 <jbowler> jacques: '*' characters round it
Apr 16 19:37:21 <jacques> *cool*
Apr 16 19:37:21 <Tiersten> Most stuff understands mIRC colour codes now
Apr 16 19:37:23 <jacques> hmm
Apr 16 19:37:34 <Tiersten> I've set my client to strip it out however as it's annoying usually
Apr 16 19:37:41 <jacques> ah well, my xchat doesn't do it
Apr 16 19:37:49 <Tiersten> probably need some script
Apr 16 19:37:53 <jacques> yah
Apr 16 19:42:16 <jbowler> Ok, I've got it doing a three instruction register/branch set like the delay.S code - '23' on jonslug
Apr 16 19:47:32 <jbowler> ... and 22 on openslug - so that's 22 seconds for two register-register instructions and a branch 1000000000 times
Apr 16 19:48:21 <jbowler> 136M instructions per second.
Apr 16 19:48:41 <jbowler> BBL: got to eat...
Apr 16 19:48:50 <ka6sox-away> thanks jbowler 
Apr 16 19:48:58 <ka6sox-away> this is helping a lot
Apr 16 19:49:01 <jacques> yeah, thanks
Apr 16 19:53:05 <ka6sox-away> Mollassas Chips
Apr 16 19:53:07 <ka6sox-away> oops
Apr 16 19:53:51 <ka6sox-away> but they are good ;)
Apr 16 19:54:19 <jacques> :-)
Apr 16 19:54:31 <jacques> speaking of which, I need to start thinking about food
Apr 16 19:55:15 <ka6sox-away> See's Molassas Chips
Apr 16 20:57:05 <jbowler> hi [g2]
Apr 16 21:10:58 <rwhitby-away> eno: major 4.x addition is loading rootfs from disk (not just packages).  this is bringing 2.x functionality back, but with more generality about where to load the rootfs from (jffs2, disk, nfs, etc).
Apr 16 21:14:40 <eno> thanks rwhitby-away 
Apr 16 21:15:51 <ka6sox-away> jbowler, rats...he was there and gone fast.
Apr 16 21:16:29 <jbowler> no - still here...
Apr 16 21:17:22 <jbowler> oh, [g2] - yes, some network problem...
Apr 16 21:18:47 <jbowler> ka6sox-away: I ran another confirmation of the instruction speed (with more register-register instructions).  It definately is 133MIPs...
Apr 16 21:19:30 <eno> i know it's trivial, i did a dhrystone ipk, any use for you guys?
Apr 16 21:19:49 <jacques> jbowler, it's 133MIPS with which kernel?
Apr 16 21:19:53 <jacques> (or both?)
Apr 16 21:20:28 <jbowler> jacques: both - the BogoMIPS report and /proc/cpuinfo is the only difference.  The real speed of the slug is identical!
Apr 16 21:21:06 <jbowler> I'm thinking that something gets reset or changed early in the bootstrap and the order wrt BogoMIPS got changed.
Apr 16 21:21:27 <jacques> jbowler, OK, not what I wanted to hear but it sounds like a mystery is finally solved :-)
Apr 16 21:21:39 <jacques> I was really hoping to be able to double the speed :-D
Apr 16 21:23:12 <jbowler> jacques: well, 133MIPS is wrong, unless there's something I don't understand.  266MHz should mean 266M 32 bit words from the DRAM (streaming) every second
Apr 16 21:23:50 <jacques> hmm
Apr 16 21:23:59 <jbowler> So that means the CPU should be able to execute 266M instructions (32 bit) every second - 266MIPS, and it's only executing 133...
Apr 16 21:24:19 <jacques> unless memory bus is 1/2 FSB ?
Apr 16 21:25:21 <jacques> or rather 1/2 cpu clock
Apr 16 21:25:23 <jbowler> Um, ok - I keep thinking of ARM2, pre-cache.  The streaming mode is irrelevant (or should be) because the instructions come from the cache.
Apr 16 21:25:55 <jbowler> The cache runs at core speed.
Apr 16 21:26:12 <jacques> ah, ok
Apr 16 21:26:33 <jacques> BIAB
Apr 16 21:26:55 <jbowler> Now, if the cache got disabled, then the DRAM streaming speed (which is one word/clock cycle) would matter...
Apr 16 21:31:42 <jbowler> jacques: goofy, the SDRAM does run at 133MHz.  Could something be disabling the I-Cache?  That would make perf really suck...
Apr 16 21:32:05 <ka6sox> that could happen.
Apr 16 21:32:41 <jbowler> ka6sox: yes, it's really easy ;-)  But how to find out...  That should be easy too.
Apr 16 21:55:57 <jbowler> jacques, ka6sox: I'm not good on the co-proc instructions, but the lines preceding 613 (the return) in arch/arm/mm/proc-xscale.S(_xscale_setup) seem weird to me.  They read the I-cache register into r0, set and clear bits, then do nothing with the result?
Apr 16 21:59:51 <jacques> back
Apr 16 22:01:28 <jacques> probably not related, but one of the reasons the PXA255 performs better than PXA250 under linux is that the write-through cache had to be disabled on the PXA250 due to errata
Apr 16 22:01:51 <jacques> there used to be a kernel config to enable it if one knew one was only going to run on a PXA255
Apr 16 22:02:29 <jbowler> Yes, well, it also occured to me that Intel may have made the timings such that the core couldn't get data faster than the memory in this (266MHz) xscale...
Apr 16 22:03:53 <jacques> curiouser
Apr 16 22:03:56 <CIA-9> 03jp30 * 10unslung/make/rsync.mk: correct uri for rsync 2.6.3
Apr 16 22:04:37 <rwhitby-away> ah - that explains the rsync confusion ...
Apr 16 22:06:36 <jbowler> rsync - even stranger the bitbake tree has rsync_2.6.4 but a directory for rsync-2.6.3...
Apr 16 22:06:37 <rwhitby-away> eno: unslung 4.x is designed such that recovery should always be as easy as unplugging the disk, rebooting, plugging back in the disk, and re-running unsling (and resling if you want to restore other changes outside /opt and /unslung).
Apr 16 22:07:35 <rwhitby-away> those wacky #oe guys ....
Apr 16 22:07:57 <ka6sox-away> oh?
Apr 16 22:08:19 <rwhitby-away> re jbowler's comment
Apr 16 22:08:26 <kergoth> jbowler: not that strange.  at one point probably both 2.6.3 and 2.6.4 were in the tree, 2.6.4 didnt need the files in that directory, and someone removed the 2.6.3 .bb and forgot the other files
Apr 16 22:08:29 <kergoth> (speculation)
Apr 16 22:09:00 <rwhitby-away> kergoth: what do you think of the git development?  I'm following the mailing list with keen interest.
Apr 16 22:09:27 <kergoth> i havent looked into it much.  been kinda depressed lately, havent paid much attention to anything.  i'm like a week behind on email
Apr 16 22:09:31 <kergoth> heh
Apr 16 22:09:58 <rwhitby-away> the git mailing list is a very good place to watch Linus in his element.
Apr 16 22:57:53 <rwhitby-away> jp30-work: ping
Apr 16 23:04:06 <ka6sox-away> ~seen jp30-work 
Apr 16 23:04:10 <jbot> jp30-work is currently on #nslu2-linux (1d 11h 36m 46s).  Has said a total of 30 messages.  Is idling for 1d 5h 56m 45s
Apr 16 23:05:27 <rwhitby-away> ok, I'm rebuilding unslung packages in a separate area on nudi. If it all succeeds I will push a feed update.
Apr 16 23:06:53 <ka6sox-away> okay very well
Apr 16 23:07:11 <ka6sox-away> did you read the discussion up above re: CoreFreq?
Apr 16 23:07:16 <rwhitby-away> yep
**** ENDING LOGGING AT Sat Apr 16 23:59:56 2005