On Sun, Jul 04, 2004 at 09:27:04PM +0200, Gabriel Wicke wrote: > On Sat, 2004-07-03 at 11:07 +0100, Gareth Bult wrote: > > Hi, > > > > ccsd starts a number of threads .. > > > > pick the one eating the CPU and "strace -p" it .. > > Thanks for this tip, i found some information that might be useful. > There's only one thread created that doesn't show up in ps aux or top, > but it's possible to connect to it by using strace -p pid-of-parent+1. > Output is heaps of lines like this, constantly looping/scrolling: > > socket(PF_BLUETOOTH, SOCK_DGRAM, 3) = -1 ENETDOWN (Network is down) > > So i suspected some weird Bluetooth/GFS interaction. Recompiled the > kernel with Bluetooth support disabled, but same thing. ccs_test seems > to work however, the results returned are correct. I've since double- > checked cluster.xml a few times, that's very likely not the reason > (posted it at http://dl.aulinx.de/gfs/cluster.xml). The bluetooth thing is a red-herring. The cluster socket type clashes with AF_BLUETOOTH and strace knows about the "real" one. we need to register the AF_type properly. CCS seems to poll for the cluster to be ready so it can enable updates - maybe it's just doing that rather too enthusiatically :-) patrick
