Hi,
I've just made a port for FreeBSD 7 and FreeBSD 6 for the
Open-vmware-tools. Any Feedback is welcome.
http://antispam.imp.ch/patches/open-vmware-tools-freebsd-port.tgz
--
Martin
Martin Blapp, <[EMAIL PROTECTED]> <[E
Hi,
Thanks for doing this, seems to be some problems with the downloading of the
tarball though. See below:
Just fixed that. The problem was the subdir name.
--
Martin
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL
l, I get smiliar segfaults. libc_r.6 is a userland
threading library, so it's definitly not the kernel which has a problem.
Are there known bugs with mimedefang on 64bit architectures ?
--
Martin
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
GV SIG_DFL
33960 mimedefang CALL kse_thr_interrupt(0,0x4,0xb)
33960 mimedefang NAMI "/var/core/mimedefang-33960.core"
--
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
-
Hi,
Looks like I found the problem and it was a local patch - ouch. Some
casts that worked in i386 didn't work on amd64 ... sigh.
Sorry for the noise.
--
Martin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fre
t top is broken (in 6.1 RELEASE too), or if this
is a SCHED4BSD bug.
Can someone confirm this issue ? We see it on IBL X-Series 346 Boxes,
as on IBM 306M Dual Core SMP systems.
Martin
Martin Blapp, <[EMAIL PROTECTED]> <[E
UN2 0:03 22.81% test
21638 root1 1030 1216K 420K RUN 2 0:03 21.79% test
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln,
Hi,
Yes HTT is disabled (by default as I tought also by freebsd). But shouldn't top
show then the correct results ?
Martin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any
rrects the top usage.
On two other boxes where it works I get 'sysctl -a | grep smp | grep
kern.smp.cpus' kern.smp.cpus: 2
Here I see CPU-ID's 0 and 1 in top. Here everything works as it should.
Martin
Martin Blapp, <[EMAIL P
Hi,
Disable hyperthreading in your BIOS.
Off course this is a solution, but I don't like
it. On a untuned, unmodified, unpatched system top(1)
should display the correct values IMHO.
Martin
___
freebsd-stable@freebsd.org mailing list
http://lists.f
rtual tty codepaths.
http://antispam.imp.ch/08-opensource.html
Martin
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00
Hi,
1.) Bad ram ? Have you run some memory tester ?
2.) Have you background fsck running on this disk ? If
so try to boot into single user and do a full fsck on this
disk.
Martin
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL
Hi,
Will you MFC before Beta 2 ?
Martin
- } else if (req == RTM_ADD && SDL(gate)->sdl_alen == 0) {
+ } else if (req == RTM_ADD && SDL(gate)->sdl_alen == 0 &&
+ (rt->rt_flags & RTF_HOST) != 0) {
ln->ln_state = ND6_LLINFO_INC
Hi,
I'll do an update of /usr/src/contrib/amd soon, after 6.2 is done.
Maybe we will see it then in 6.3 RELEASE :-)
Martin
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
ImproWare AG, UNIXSP & ISP
Hi,
In June 2006, I opened a PR (kern/98622) about a regression on CARP
with IPv6 addresses: CARP is not usable with IPv6. Since I tracked
down the culprit commit (see appropriate info in the PR), I can
affirm that this regression appeared before the 6.1-RELEASE.
Wouldn't it be better to fix
Hi,
What about with just the first change and not the second? Anyways, I'm
starting to see a trend here. Problem reports are clustering around UP
systems, not SMP systems. I don't know if that's just coincidence or not.
We've got also about twenty SMP Systems, seven of them now with 6.1 P
Hi,
Also, the only harddisk on that host is the ips(4), so I can not obtain
a kernel dump. I'm not sure if this is a hardware failure, at least, no
led on the panel is shown red...
Hmm ? We do kernel dumps on ips(4) and it works.
dumpdev="/dev/ipsd0s1b"
Martin
__
Build 6.2-RC2 24 December 2006Begin building the second release
candidate
build for all Tier-1 platforms.
http://www.freebsd.org/releases/6.2R/schedule.html
Martin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailm
Hi,
I feel the mount_union manpage isn't 100% correct anymore, especially the
the BUGS section ? Or do the things there still apply ?
Martin
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
ImproWare
Hi,
Change the threading lib. It fixed it for us.
% cat /etc/libmap.conf
[clamd]
libc_r.so.5 libthr.so.2
libc_r.so.6 libthr.so.2
libthr.so.2 libthr.so.2
libpthread.so.1 libthr.so.2
libpthread.so.2 libthr.so.2
Even with libthr the CPU usage
Hi,
Clamd is currently broken with libpthread for some threading-reason.
You definitly need to use libthr (which is still CPU hungry, but
works better).
/etc/libmap.conf
[/usr/local/sbin/clamd]
libpthread.so.2 libthr.so.2
libpthread.so libthr.so
libc_r.so.6 libpth
Hi,
[/usr/local/sbin/clamd]
libpthread.so.2 libthr.so.2
libpthread.so libthr.so
libc_r.so.6 libpthread.so.2
Correct, just delete the last line. I forgot to delete
the only entry.
The right side of that last line should probably refer to libthr.so.2.
AFAICS, w
Hi all,
After adding some debug stuff to clamd running with freebsd
libpthread.so I found that:
looking at the output value of 'ps -auxH | grep clamd | grep -v grep | wc -l'
is always staying at 6 threads, but the number of threadpool->thr_alive is
going higher and higher. So threadpool->thr_al
Hi,
looking at the output value of 'ps -auxH | grep clamd | grep -v grep | wc -l'
is always staying at 6 threads, but the number of threadpool->thr_alive is
going higher and higher. So threadpool->thr_alive isn't decreased and
is completly incorrect.
After setting IdleTimeout very low to 5 se
Hi,
Make sure clamd is checking the return value of pthread_create()
for errors. You can also set LIBPTHREAD_PROCESS_SCOPE=yes or
LIBPTHREAD_SYSTEM_SCOPE=yes in your environment to force process
scope or system scope threads (libpthread only) for clamd.
Yes, it does check the return value. A
time
specified in abstime, and the current thread reacquires the lock on
mutex.
That doesn't seem to work with libpthread.so.2. Any hints ?
--
Martin
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
-
Hi,
No, It's not. Today I added a new server with fresh clamav-0.90_3
package. Sockstat again started to jump to the sky.
Clamd with libpthread.so is still broken. Please use libthr.so. I'm currently
investigating why libpthreads.so has problems with clamd, and it looks to me
like a library b
Hi,
Don't use it, it's broken.
-trog
Nope, it looks like a race in cli_scanmail() which deadlocks somewhere
with libpthread.so. This workaround fixes the problem for me. I'm still
investigating where the real cause for this problem is.
--- libclamav/scanners.cTue Feb 13 02:06:28 200
lock(&body_mutex);
/*
* Tidy up and quit
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93
Hi,
[snip patch]
Does this patch make the libmap.conf hack unneeded?
I frist thought so, but no, the more threads are running concurrently
the slower libpthreads behaves, as it gets more lock contention. Until
this is addressed somehow, use libthr.so
--
Martin
_
Hi,
I just fixed those issues with the port.
Thanks for reporting !
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 9
Hi,
I am not sure why. But my dual xeon with libthr on clamav-90.1 still gives
very high cpu usage.
It's the same case here. What happens if you limit kern.smp.maxcpus
to 1 ? Does it still use the same amount cpu time ? What happens if
you link clamd against libc_r ?
--
Martin
__
= -349046324})at /usr/src/sys/i386/i386/trap.c:435
#8 0xc0879d4a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#9 0xc088c076 in slow_copyin () at /usr/src/sys/i386/i386/support.s:872
Martin Blapp, <[EMAIL PROTEC
Hi,
Can you post your kernel configuration file?
It's the generic SMP kernel file (which includes GENERIC), with
nothing changed.
sysctl.conf is:
kern.sugid_coredump=1
kern.timecounter.hardware=TSC
kern.corefile=/var/core/%N-%P.core
kern.maxfiles=64000
kern.maxfilesperproc=32000
The server
_read: invalid address (0x21)
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP:
PGP Fingerprint
S.
Martin
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP:
PGP Fingerprint: B434 53FC C87
Hi,
Unfortunaltly I get this with the debug kernel.
Does one have to boot with the debug.kernel itself
to get a trace which is usable ?
Sigh. A recompile helped !
(kgdb) where
#0 doadump () at pcpu.h:165
#1 0xc066355e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc0663
Hi,
(kgdb) p *tp->t_session
Cannot access memory at address 0x0
So here the problem is. Why is tp->t_session empty ? Maybe it has been already
free() earlier and we have some race here ?
"Race" was exactly my conclusion last time I looked into this.
http://docs.FreeBSD.org/cgi/mid.cgi?200412
Hi,
Maybe this is the solution ? IMHO there is a race window
open between the first tp->t_session test and the locking
of the proc tree.
Martin
+++ src/sys/kern/tty.c
--- src/sys/kern/tty.c
+ sx_slock(&proctree_lock);
if (tp->t_session) {
-
Hi,
I'm not sure if t_session is supposed to be protected by the proctree
Correct.
lock though. With an initial glance of the code, it would seem odd to
be protected by the proctree lock, although I can't see any other locks
Someone with more knowledge of this code will probably know the a
Hi Max, Robert and Gavin,
Note, I am not sure if the patch still applies or is correct at all, but from
looking at it (and the name of the file) I seem to remember that there was a
problem with t_pgrp and t_session being accessed unlocked in some places.
Maybe it helps, maybe it doesn't.
[1] h
in the previous patch. I've put the
modified one at:
http://mx.imp.ch/patch-tty.t_pgrp.diff
Thanks for testing !
Martin
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
ImproWare AG, UNIXSP & ISP, Zurlinde
Hi all,
So far so good.
A remote stress testing of a tty session over serial cable
with a patched kernel worked fine.
How to proceed now ? The patch also applies to CURRENT
as there where no big changes since the repo has been
branched.
Should I commit it to CURRENT ?
http://mx.imp.ch/patch
Hi,
Is the problem actually understood? Do we know what's racing with what?
Given there only ever seems to be a single backtrace involved, as far as
I can tell, it's ttymodem racing with tty_close - can those two
functions alone be locked?
Correct: The only place there tp->t_session is set t
Hi,
I suspect a wrong library, thus it is the linux_base port. Can you
do some debugging with kdump and strace ?
Martin
Martin Blapp, [EMAIL PROTECTED]
--
Improware AG, UNIX solution and service provider
Zurlindenstrasse 29, 4133
Hi Keltia,
> According to Martin Blapp:
> > I see something similar here. Nsrexec, a networker client
> > which gets started in rc.d segfaults since 1-2 month here.
>
> Ask Matt for a 6.0 client. He recompiled one two months ago and it has stopped
> segfaulting for me on
Hi Greg.
> As I've mentioned elsewhere, this is seriously suboptimal. The
> "mirror" command is a toy for people getting used to Vinum. You want
Why is this suboptimal ? It's fast done. It seems to work. Else you
have to say: "not supported, since it can panic your machine".
> a proper confi
Hi all,
> I tried looking, but the net connection was terrible. Anyway, I've
> been able to reproduce it here, and I have a patch which should make
> it go away:
Just tried the patch and it fixes my problem completly. Thanks
Thomas for the excelent work you've done.
And thank you Greg for pro
Greg,
> As I've mentioned elsewhere, this is seriously suboptimal. The
> "mirror" command is a toy for people getting used to Vinum. You want
> a proper config file. Then create one drive per spindle, and choose
> your subdisk sizes to match what you want. Specifically, your config
> file sh
Hi Greg,
> So it seems. I've heard of this in a couple of cases. It would be
> interesting to see the log output, but if I understand you correctly
> you have since found a way to work around the problem. I suspect that
> there was something in the disk label which confused the issue, but it
dc_link;
u_int8_tdc_cachesize;
+ int dc_romwidth;
int dc_pnic_rx_bug_save;
unsigned char *dc_pnic_rx_buf;
int dc_if_flags
Hi,
> Did you notice what the wait channel was? If the machine is still
> there, you could hit ^T and see what it says.
I just reproduced it on a second faster server. The file is also
80GB big.
Unfortunatly I lost the link of my ssh connection. After
~10 mins the server was again running and u
52 matches
Mail list logo
