I tried rebooting, and then I had 277 megs of ram free. Then I ran setiathome again, and got the same result. I'm pretty sure that ram usage is not the problem. Seti never uses more than about 12 megs, and I always have at least 50 (and sometimes up to 250 megs free). My version of 10.2 is actually a clean install. I screwed up my partitioning (basically ran out of room on the one where I needed it) so I had to repartition and reinstall the OS. This was a problem before the repartitioning as well though, so it didn't start there. It started at (or near) the time that I upgraded to 10.2 In order to possibly clear up any questions about my system configuration I'm going to attach my system profiler file here. It's big, I know. Hopefully this won't upset anyone too much.....
---------------------------------------------------
System Profile
---------------------------------------------------
Software Overview:
+----------------------------------------------------------------------
+
|
|
| System version : Mac OS X 10.2.2 (6F21)
|
| Boot volume : OSX
|
| Kernel version : Darwin Kernel Version 6.2: Tue
Nov 5 22:00:03 PST 2002; root:xnu/xnu-344.12.2.obj~1/RELEASE_PPC |
| User name : Tyler Ward (tyler)
|
|
|
+----------------------------------------------------------------------
+
Hardware Overview:
+----------------------------------------------------------------------
+
|
|
| Machine speed : 450 MHz
|
| Bus speed : 100 MHz
|
| Number of processors : 1
|
| L2 cache size : 1MB
|
| Machine model : Power Mac G4 Cube (version =
2.9) |
| Boot ROM info : 4.1.9f1
|
| Customer serial number : SG0331SA-K59-ff06
|
| Sales order number : Not available
|
|
|
+----------------------------------------------------------------------
+
I omitted the logs and frameworks, because they're even bigger.... Beyond that, I'm not sure what to do. This isn't really a problem for me, after all, what do I care how fast my seti client crunches work units. I'm not losing sleep over it. However, there are those that might care, and if this is an actual reproduceable bug it might be quite a big one. Who knows, maybe top's just misreporting everything. Now here's something interesting.... I'm going to use quoting to set off the data, this isn't really quoting from another email.... I watched it in top delta (sampling every three seconds to make sure top overhead is small) mode for awhile.... I found that it generally looks like this.....
443 setiathome 80.0% 14:50.38 257 0/0 5/5 30/5
612
However the system mode percentage says 20% or so anyway. But as I was watching it, it suddenly jumped to this.....
443 setiathome 91.4% 14:16.47 0 0/0 0/0 7343/0
678
Notice the 7343 BSD syscalls. That however appeared to have little effect on its use of system time. Apparently that never showed up in the ktrace because I never happened to be tracing when it went psycho. That's where all the missing syscalls are coming from apparently. But it doesn't seem to affect the system time percentage much, so that's apparently not the problem either. I actually did a ktrace on it while it was freaking out, apparently it goes into a semi-infinite loop calling 539 setiathome CALL getrusage(0,0xbffff6a8) 539 setiathome RET getrusage 0 539 setiathome CALL getrusage(0,0xbffff6a8) 539 setiathome RET getrusage 0 539 setiathome CALL getrusage(0,0xbffff6a8) 539 setiathome RET getrusage 0 I have about a thousand pages of that. :-) But I'm not sure that's really the problem either, though I reported it to setiathome anyway. Tyler Ward _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.