It's possible - sort of, and in some situations - to figure out which thread
library is being used and what the version of glibc is.

The question then becomes whether we can use this information to avoid the
syslog() wrapping mutex calls if we KNOW that we don't need them.

1. The default (including unkown information case) needs to be to use the
mutex() calls.

2. We need to identify the specific case(es) which we know are safe.  And do
it in such a way that when ntop hits something new, it will handle it
properly.


I see a couple of alternatives.

1. Reverse the meaning of the -D flag and require explicitly it be present
in configureextra/ files where we know we can skip the calls, e.g. FC2/3.

2. Do some sort of run-time testing.



Thoughts?

-----Burton 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Florin
Sent: Monday, April 04, 2005 2:59 PM
To: [email protected]
Subject: Re: [Ntop-dev] 3.1 Hang Info (was: SMP linux hangs with ntop)

Did the ntop part of the hacking and it seems to work, except that it uses
99% of CPU 1 (well, kinda, since it's still Pentium 4 HT ).
Concerning the glibc bug, it seems having been fixed in Mandrake 9.2 in a
personal way (the patch is present but modified). 
Trying to replace syslog.c with the version proposed on the redhat site
requires a lot of hack to compile glibc, but I did it. Except that it
doesn't make it more stable, cause they replace pthread_cleanup_push/pop
with some empty macros that have no effect. The result is that some services
hang (things getting worse :) ). So I turned back to the original glibc
version recompiled with linuxthreads_db enabled (disabled linuxthreads_db
was a known bug in Mandrake 9.2).
Having more time to run the SMP Mandrake kernel 2.4.22, I noticed however
that it is less stable than the uniprocessor kernel (sometimes the system
hangs anyway with or without ntop running), so I suppose Pentium 4 HT
support is not great in Mandrake 9.2 overall. As ennoying it can be, I might
consider upgrading the distribution before doing anything more. Anybody had
similar troubles with these processors/dual channel DDR Intel mobo? Cause I
have 2 identical machines and they behave both the same way.
Florin
 

<snip />


_______________________________________________
Ntop-dev mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev

Reply via email to