Re: Open-vm-tools port available for testing
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 PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Open-vm-tools port available for testing
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] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Mimedefang crashes on FreeBSD 6 STABLE, amd64
Hi everybody,
I'm trying to get mimedefang running on amd64. But unfortunatly the threaded
milter part ('mimedefang') does segfault after some time, normally 1-2 minutes.
pid 2331 (mimedefang), uid 1001: exited on signal 11 (core dumped)
gdb /idms/bin/mimedefang mimedefang-2331.core
#0 0x00080066389c in pthread_testcancel () from /lib/libpthread.so.2
[New Thread 0x56 (runnable)]
[New Thread 0x599800 (runnable)]
[New Thread 0x546c00 (runnable)]
[New Thread 0x5ad400 (runnable)]
[New Thread 0x5ad000 (runnable)]
[New Thread 0x599c00 (runnable)]
[New Thread 0x560800 (runnable)]
[New Thread 0x55e800 (runnable)]
[New Thread 0x55ec00 (runnable)]
[New Thread 0x55e400 (runnable)]
[New Thread 0x560c00 (runnable)]
[New Thread 0x58fc00 (runnable)]
[New Thread 0x57fc00 (runnable)]
[New Thread 0x599000 (runnable)]
[New Thread 0x52ac00 (runnable)]
[New Thread 0x57f800 (runnable)]
[New Thread 0x58f000 (runnable)]
[New Thread 0x57f400 (runnable)]
[New Thread 0x58f800 (runnable)]
[New Thread 0x52a800 (runnable)]
[New Thread 0x57f000 (runnable)]
[New Thread 0x546800 (runnable)]
[New Thread 0x52a400 (sleeping)]
[New Thread 0x52a000 (LWP 100058)]
[New Thread 0x524000 (runnable)]
[New LWP 100266]
Unfortunaltly the stack trace doesn't seem to be very usable:
(gdb) where
#0 0x00080066c3fc in kse_thr_interrupt () at kse_thr_interrupt.S:2
#1 0x00080065390a in sig_daemon (arg=0x0) at
/usr/src/lib/libpthread/thread/thr_sig.c:214
#2 0x000800661e2e in kse_sched_single (kmbx=0x521318) at
/usr/src/lib/libpthread/thread/thr_kern.c:886
#3 0x in ?? ()
Cannot access memory at address 0x7fbff000
(gdb) frame 2
#2 0x000800661e2e in kse_sched_single (kmbx=0x521318) at
/usr/src/lib/libpthread/thread/thr_kern.c:886
886 pthread_exit(curthread-start_routine(curthread-arg));
(gdb) p kmbx
$1 = (struct kse_mailbox *) 0x521318
(gdb) p *kmbx
$2 = {km_version = 0, km_curthread = 0x0, km_completed = 0x0, km_sigscaught =
{__bits = {0, 0, 0, 0}}, km_flags = 19,
km_func = 0x800661560 kse_sched_single, km_stack = {ss_sp = 0x7f9ff000
Address 0x7f9ff000 out of bounds,
ss_size = 2097152, ss_flags = 0}, km_udata = 0x51c600, km_timeofday =
{tv_sec = 0, tv_nsec = 0}, km_quantum = 0, km_lwp = 100058,
__spare2__ = {0, 0, 0, 0, 0, 0, 0}}
I've tried to replace libpthread.so.2 with libc_r.6 or libthr.2, but
this doesn't help at all, 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]
--
ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP: finger -l [EMAIL PROTECTED]
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mimedefang crashes on FreeBSD 6 STABLE, amd64
A kdump output shows always the same output. The file descriptor '108/0x6c' doesn't look very valid -- 36626 mimedefang RET kse_release 0 36626 mimedefang RET kse_release 0 36626 mimedefang RET fork 0 36626 mimedefang CALL kse_release(0x537f70) 36626 mimedefang RET kse_release 0 36626 mimedefang RET kse_release 0 36626 mimedefang CALL kse_release(0x521f70) 36626 mimedefang CALL gettimeofday(0x7f5f8eb0,0) 36626 mimedefang CALL kse_release(0x53ff70) 36626 mimedefang CALL kse_release(0x53bf70) 36626 mimedefang RET kse_release 0 36626 mimedefang RET kse_release 0 36626 mimedefang CALL kse_release(0x521f70) 36626 mimedefang CALL getpid 36626 mimedefang RET getpid 36626/0x8f12 36626 mimedefang CALL sendto(0x3,0x7f5f93b0,0x6c,0,0,0) 36626 mimedefang GIO fd 3 wrote 108 bytes 20Oct 19 11:55:57 mimedefang[36626]: 5422080 - 0x540c00: mimedefang.c(1924): EXIT cleanup: SMFIS_CONTINUE 36626 mimedefang RET sendto 108/0x6c 36626 mimedefang CALL gettimeofday(0x7f5f8f10,0) 36626 mimedefang RET gettimeofday 0 36626 mimedefang CALL getpid 36626 mimedefang RET getpid 36626/0x8f12 36626 mimedefang CALL sendto(0x3,0x7f5f9410,0x6c,0,0,0) 36626 mimedefang GIO fd 3 wrote 108 bytes 20Oct 19 11:55:57 mimedefang[36626]: 5422080 - 0x540c00: mimedefang.c(1888): EXIT mfclose: SMFIS_CONTINUE 36626 mimedefang RET sendto 108/0x6c 36626 mimedefang PSIG SIGSEGV SIG_DFL 36626 mimedefang CALL kse_thr_interrupt(0,0x4,0xb) 36626 mimedefang NAMI /var/core/mimedefang-36626.core -- 20Oct 19 11:53:03 mimedefang[33960]: 5422080 - 0x51de00: mimedefang.c(1922): ENTER cleanup 33960 mimedefang RET sendto 93/0x5d 33960 mimedefang CALL gettimeofday(0x7f5f8eb0,0) 33960 mimedefang RET gettimeofday 0 33960 mimedefang CALL getpid 33960 mimedefang RET getpid 33960/0x84a8 33960 mimedefang CALL sendto(0x3,0x7f5f93b0,0x6c,0,0,0) 33960 mimedefang GIO fd 3 wrote 108 bytes 20Oct 19 11:53:03 mimedefang[33960]: 5422080 - 0x51de00: mimedefang.c(1924): EXIT cleanup: SMFIS_CONTINUE 33960 mimedefang RET sendto 108/0x6c 33960 mimedefang CALL gettimeofday(0x7f5f8f10,0) 33960 mimedefang RET gettimeofday 0 33960 mimedefang CALL getpid 33960 mimedefang RET getpid 33960/0x84a8 33960 mimedefang CALL sendto(0x3,0x7f5f9410,0x6c,0,0,0) 33960 mimedefang GIO fd 3 wrote 108 bytes 20Oct 19 11:53:03 mimedefang[33960]: 5422080 - 0x51de00: mimedefang.c(1888): EXIT mfclose: SMFIS_CONTINUE 33960 mimedefang RET sendto 108/0x6c 33960 mimedefang PSIG SIGSEGV 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] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Mimedefang] Re: Mimedefang crashes on FreeBSD 6 STABLE, amd64
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/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic: vm_page_free: freeing wired page with 6.2 RELEASE
Hi,
Just got this panic on a loaded mailserver ... The server was rocking stable
up to this panic, and after we loaded it a bit more recently, it paniced.
Any ideas ?
--
Martin
#0 doadump () at pcpu.h:165
#1 0xc067550a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc0675831 in panic (fmt=0xc0915bd0 vm_page_free: freeing wired page) at
/usr/src/sys/kern/kern_shutdown.c:565
#3 0xc07f15a3 in vm_page_free_toq (m=0xc25380b0) at
/usr/src/sys/vm/vm_page.c:1131
#4 0xc07f0ad1 in vm_page_free (m=0xc25380b0) at /usr/src/sys/vm/vm_page.c:471
#5 0xc07e4be0 in vm_fault (map=0xcadcf378, vaddr=678141952, fault_type=1
'\001', fault_flags=0)
at /usr/src/sys/vm/vm_fault.c:632
#6 0xc088df07 in trap_pfault (frame=0xeb31f820, usermode=0, eva=678141952) at
/usr/src/sys/i386/i386/trap.c:722
#7 0xc088dc15 in trap (frame= {tf_fs = -1065549816, tf_es = -65496, tf_ds = -65496, tf_edi = -548069376,
tf_esi = 678141952, tf_ebp = -349046640, tf_isp = -349046708, tf_ebx = 16384,
tf_edx = 678158336, tf_ecx = 4096, tf_eax = -349045504, tf_trapno = 12, tf_err =
0, tf_eip = -1064779658, tf_cs = 32, tf_eflags = 66054, tf_esp = -349046248,
tf_ss = -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 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: finger -l [EMAIL PROTECTED]
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic: vm_page_free: freeing wired page with 6.2 RELEASE
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 has two CPUs. The only special thing is that with the current BIOS ACPI is broken. -- Martin FreeBSD 6.2-RELEASE #0: Tue Jan 23 11:13:16 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (3000.13-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf43 Stepping = 3 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE, SSE2,SS,HTT,TM,PBE Features2=0x641dSSE3,RSVD2,MON,DS_CPL,CNTX-ID,CX16,b14 AMD Features=0x2000LM Logical CPUs per core: 2 real memory = 3623665664 (3455 MB) avail memory = 3546501120 (3382 MB) MPTable: IBM ENSW x346 SMP FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0: Assuming intbase of 0 ioapic1: Assuming intbase of 24 ioapic2: Assuming intbase of 48 ioapic3: Assuming intbase of 72 ioapic4: Assuming intbase of 96 ioapic4 Version 2.0 irqs 96-119 on motherboard ioapic3 Version 2.0 irqs 72-95 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ACPI-0159: *** Error: AcpiLoadTables: Could not get RSDP, AE_NO_ACPI_TABLES ACPI-0213: *** Error: AcpiLoadTables: Could not load tables: AE_NO_ACPI_TABLES ACPI: table load failed: AE_NO_ACPI_TABLES cpu0 on motherboard cpu1 on motherboard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Clamav-90_2 Lockup with freebsd 6.2
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
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 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
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 2007
+++ libclamav/scanners.cSat Mar 10 12:00:16 2007
@@ -38,6 +38,9 @@
#include netinet/in.h
#endif
+# include pthread.h
+static pthread_mutex_t extractmail_mutex = PTHREAD_MUTEX_INITIALIZER;
+
#if HAVE_MMAP
#if HAVE_SYS_MMAN_H
#include sys/mman.h
@@ -1652,12 +1655,16 @@
/*
* Extract the attachments into the temporary directory
*/
+pthread_mutex_lock(extractmail_mutex);
if((ret = cli_mbox(dir, desc, ctx))) {
- if(!cli_leavetemps_flag)
+ if(!cli_leavetemps_flag) {
+ pthread_mutex_unlock(extractmail_mutex);
cli_rmdirs(dir);
+ }
free(dir);
return ret;
}
+pthread_mutex_unlock(extractmail_mutex);
ret = cli_scandir(dir, ctx);
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
And even more narrowed down ...
--- libclamav/mbox.c.orig Tue Feb 13 14:06:57 2007
+++ libclamav/mbox.cSat Mar 10 14:09:09 2007
@@ -413,6 +413,7 @@
#ifdef CL_THREAD_SAFE
static pthread_mutex_t tables_mutex = PTHREAD_MUTEX_INITIALIZER;
+static pthread_mutex_t body_mutex = PTHREAD_MUTEX_INITIALIZER;
#endif
#ifndefO_BINARY
@@ -1494,6 +1495,7 @@
/*
* Write out the last entry in the mailbox
*/
+ pthread_mutex_lock(body_mutex);
if((retcode == CL_SUCCESS) messageGetBody(body)) {
messageSetCTX(body, ctx);
switch(parseEmailBody(body, NULL, mctx, 0)) {
@@ -1505,6 +1507,7 @@
break;
}
}
+ pthread_mutex_unlock(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 01
PGP: finger -l [EMAIL PROTECTED]
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
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 bug. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2 (fwd)
After further analyzing I think that pthread_cond_timedwait() in libpthread.so.2 has some issues. While the default clamd worker timeout of 30 seconds is reached with libc_r.so.6 and libthr.so.2 and pthread_cond_timedwait() returns ETIMEDOUT there, libpthread.so doesn't get any ETIMEDOUT errors back at all, and the code can never reach the part where the worker thread gets detached and the thread count gets decreased. With libpthread.so.2 pthread_cond_timedwait() returns always 0. The manpage tells me: The pthread_cond_timedwait() function atomically blocks the current thread waiting on the condition variable specified by cond, and unblocks the mutex specified by mutex. The waiting thread unblocks only after another thread calls pthread_cond_signal(3), or pthread_cond_broadcast(3) with the same condition variable, or if the system time reaches the 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] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
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_alive isn't decreased and is completly incorrect. In my tests the number of threads with libpthread.so is never going higher than 6 threads. That explains, why a higher load is going to delay all scan operations more and more. With libthr.so the value of threadpool-thr_alive is equal with the output of the ps. It can go very high, but always goes back if no more work is there to do. After the maxthreads limit is reached, clamd becomes completly unresponsive with libpthreads.so. SIGKILL and SIGSTOP don't work because some (unexisting) worker threads block on pthread_cond_timedwait(). Only kill -9 helps. Of course, the counter threadpool-thr_alive is wrong and may cause this problem. Maybe someone with more threads knowledge can help here. I'll now add some debug stuff to see where threadpool-thr_alive is going to be increased and where it is decreased. The strange thing is that this works fine with libthr.so. Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
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 seconds, the threadpool-thr_alive gets decreased correctly. There are still always 6 threads running, but further threads get cleaned up correctly. IMHO the whole clamd thread management is somehow broken. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
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. And setting system or process scope doesn't make any difference. As I said, increasing the thread count works, decreading doesn't. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
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, what you have there makes no sense. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
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 libpthread.so.2 Martin Dozens? Lucky you. I had 600 of them. OK, now we know that simscan is not the problem. -- One cannot sell the earth upon which the people walk Tacunka Witco ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
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 is still far too high ... I'm currently looking at the code. Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HEADSUP] New unionfs merged to RELENG_6 (stable)
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 AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- On Wed, 14 Feb 2007, Craig Rodrigues wrote: Hi, I have merged the new unionfs implementation from CURRENT to RELENG_6 (stable branch). This code was submitted by Daichi GOTO and Masanori OZAWA. Many, many thanks to GOTO-san and OZAWA-san for their work. This code solves a lot of crashing problems that the old unionfs implementation had. Reports from people running SMP systems would be appreciated. There probably is some room for performance optimization on SMP systems. Also, thanks a lot to Kostik Belousov, who recently fixed some deadlock problems in vfs_lookup.c, which helps a lot with unionfs. -- Craig Rodrigues [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of FreeBSD 6.2?
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/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ips(4) in toaster mode
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon
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 this in RELENG_6 before 6.2 RELEASE ? Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CALL FOR TESTERS! [Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2]
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 Prerelease and we don't have any affected systems. bge- and em- cards are working fine, even under high load situations. Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem with old /usr/src/contrib/amd
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, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- On Tue, 3 Oct 2006, Nicolas Martin wrote: Hi all, i was wondering if an update of /usr/src/contrib/amd is planned ? I encounter a problem using amd with nolock options, and it seems that this problem was fixed on recent version of am-utils. Many thanks, Nicolas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Disappearing IPv6 default route
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_INCOMPLETE;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Frequent VFS crashes with RELENG_6
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 PROTECTED]
--
ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP: finger -l [EMAIL PROTECTED]
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--
On Sat, 30 Sep 2006, Vlad GALU wrote:
I've been getting random crashes like the one below, once or twice a
week, always in the same code path. The system is a RELENG_6 as of Wed
Sep 27 11:42:57 EEST 2006, running on amd64.
-- cut here --
#0 doadump () at pcpu.h:172
No locals.
#1 0x8022d033 in boot (howto=260) at
../../../kern/kern_shutdown.c:409
first_buf_printf = 1
#2 0x8022d687 in panic (fmt=0xff002bb6e260 °ö¾\) at
../../../kern/kern_shutdown.c:565
bootopt = 260
newpanic = 0
ap = {{gp_offset = 16, fp_offset = 48, overflow_arg_area =
0xa7995790, reg_save_area = 0xa79956b0}}
buf = vm_page_unwire: invalid wire count: 0, '\0' repeats 218
times___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
TTY patches available for FreeBSD 5
Hi all, For those who are interested I've put patches for FreeBSD 5 online. Anybody having tty troubles and is using the perl module Expect, or has heavy terminal usage (sshd) on his server and occasional panics should give them a try. Those patches fix various panics in the tty and virtual 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 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Please confirm: top(1) cpu time broken on FreeBSD 6.1 (RELEASE/STABLE) SMP ?
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.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Please confirm: top(1) cpu time broken on FreeBSD 6.1 (RELEASE/STABLE) SMP ?
Hi all, I'm currently seeing strang things going on on all our upgraded SMP 2 CPU boxes. 4 Boxes are upgraded from 5.5 to 6 STABLE, one box is running 6.1 RELEASE. All of them have SMP kernels, just using the provided GENERIC and SMP kernel config files. Mergemaster has been done on all boxes. If a box is full loaded top(1) shows: CPU states: 41.7% user, 0.0% nice, 7.7% system, 0.6% interrupt, 50.0% idle I can buildworld -j 100, do verything what I want. The sum of idle time never goes below 50.0% idle ! And the sum of total CPU time never goes over 50.0%. So I wonder if just 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] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Please confirm: top(1) cpu time broken on FreeBSD 6.1 (RELEASE/STABLE) SMP ?
#include stdio.h
main() {
while(1) {}
}
cc -o test.c test
./test
./test
./test
./test
./test
./test
./test
./test
CPU states: 50.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 50.0% idle
Mem: 1160M Active, 988M Inact, 254M Wired, 34M Cache, 112M Buf, 573M Free
Swap: 8192M Total, 8192M Free
PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND
21651 root1 1040 1216K 420K RUN2 0:03 28.85% test
21653 root1 1030 1216K 420K CPU0 0 0:02 28.26% test
21649 root1 1040 1216K 420K RUN2 0:03 26.12% test
21647 root1 1030 1216K 420K RUN2 0:02 25.04% test
21650 root1 1030 1216K 420K RUN0 0:02 24.50% test
21645 root1 1030 1216K 420K RUN0 0:03 23.31% test
21646 root1 1040 1216K 420K RUN2 0:03 22.81% test
21638 root1 1030 1216K 420K RUN2 0:03 21.79% test
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: finger -l [EMAIL PROTECTED]
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Please confirm: top(1) cpu time broken on FreeBSD 6.1 (RELEASE/STABLE) SMP ?
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 mail to [EMAIL PROTECTED]
Re: Please confirm: top(1) cpu time broken on FreeBSD 6.1 (RELEASE/STABLE) SMP ?
Hi, Ok, seems to be a HTT issue on a untuned system. On two boxes I get with 'sysctl -a | grep smp | grep kern.smp.cpus' kern.smp.cpus: 4 Here I see CPU-IDs 0 and 2 in top. No other CPUs seem to be used. Here I get the broken CPU usage. And yes, seeting hyperthreading_allowed=1 corrects 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 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: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Crash with FreeBSD 6.1 STABLE of today
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] http://people.freebsd.org/~mlaier/tty.t_pgrp.diff
Some things are now different. The part at 2551,2567 has now
additional PGRP_LOCKs.
I've also added the proctree locking at line 1654 as I did in the
first patch. This part is unlocked too ... , don't you think ? That's
the place there panic appeared.
@@ -1654,8 +1668,8 @@
!ISSET(tp-t_cflag, CLOCAL)) {
SET(tp-t_state, TS_ZOMBIE);
CLR(tp-t_state, TS_CONNECTED);
+ sx_slock(proctree_lock);
if (tp-t_session) {
- sx_slock(proctree_lock);
if (tp-t_session-s_leader) {
struct proc *p;
@@ -1664,8 +1678,8 @@
psignal(p, SIGHUP);
PROC_UNLOCK(p);
}
- sx_sunlock(proctree_lock);
}
+ sx_sunlock(proctree_lock);
ttyflush(tp, FREAD | FWRITE);
return (0);
}
Also this place was unlocked:
@@ -942,8 +952,11 @@
* Policy -- Don't allow FIOSETOWN on someone else's
* controlling tty
*/
- if (tp-t_session != NULL !isctty(p, tp))
+ sx_snlock(proctree_lock);
+ if (tp-t_session != NULL !isctty(p, tp)) {
+ sx_sunlock(proctree_lock);
return (ENOTTY);
+ }
error = fsetown(*(int *)data, tp-t_sigio);
if (error)
Here is the complete patch. What do you thing about it ?
It's a FreeBSD 6 STABLE patch.
I'll test this patch now and tell you any problems with it.
Please do the same if you have time ...
Also available at:
http://mx.imp.ch/patch-tty.t_pgrp.diff
Martin
--- sys/kern/tty.c.orig Thu Dec 15 18:13:40 2005
+++ sys/kern/tty.c Mon Jun 26 12:53:33 2006
@@ -329,8 +329,10 @@
tp-t_gen++;
tp-t_line = TTYDISC;
tp-t_hotchar = 0;
+ sx_xlock(proctree_lock);
tp-t_pgrp = NULL;
tp-t_session = NULL;
+ sx_xunlock(proctree_lock);
tp-t_state = 0;
knlist_clear(tp-t_rsel.si_note, 0);
knlist_clear(tp-t_wsel.si_note, 0);
@@ -401,11 +403,13 @@
return (0);
if (ISSET(iflag, BRKINT)) {
ttyflush(tp, FREAD | FWRITE);
+ sx_slock(proctree_lock);
if (tp-t_pgrp != NULL) {
PGRP_LOCK(tp-t_pgrp);
pgsignal(tp-t_pgrp, SIGINT, 1);
PGRP_UNLOCK(tp-t_pgrp);
}
+ sx_sunlock(proctree_lock);
goto endcase;
}
if (ISSET(iflag, PARMRK))
@@ -483,23 +487,27 @@
if (!ISSET(lflag, NOFLSH))
ttyflush(tp, FREAD | FWRITE);
ttyecho(c, tp);
+ sx_slock(proctree_lock);
if (tp-t_pgrp != NULL) {
PGRP_LOCK(tp-t_pgrp);
pgsignal(tp-t_pgrp,
CCEQ(cc[VINTR], c) ? SIGINT :
SIGQUIT, 1);
PGRP_UNLOCK(tp-t_pgrp);
}
+ sx_sunlock(proctree_lock);
goto endcase;
}
if (CCEQ(cc[VSUSP], c)) {
if (!ISSET(lflag, NOFLSH))
ttyflush(tp, FREAD);
ttyecho(c, tp);
+ sx_slock(proctree_lock);
if (tp-t_pgrp != NULL) {
PGRP_LOCK(tp-t_pgrp);
pgsignal(tp-t_pgrp, SIGTSTP, 1);
PGRP_UNLOCK(tp-t_pgrp);
}
+ sx_sunlock(proctree_lock);
goto endcase;
}
}
@@ -617,11 +625,13 @@
* ^T - kernel info and generate SIGINFO
*/
if
Re: Crash with FreeBSD 6.1 STABLE of today
Hi, For those who got: /usr/src/sys/kern/tty.c: In function `ttioctl': /usr/src/sys/kern/tty.c:955: warning: implicit declaration of function `sx_snlock' /usr/src/sys/kern/tty.c:955: warning: nested extern declaration of `sx_snlock' *** Error code 1 There was a small typo 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, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Crash with FreeBSD 6.1 STABLE of today
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-tty.t_pgrp.diff Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Crash with FreeBSD 6.1 STABLE of today
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 to NULL is in tty_close(). tp-t_pgrp = NULL; tp-t_session = NULL; tp-t_state = 0; But I've seen this comment on peters page (http://people.freebsd.org/~peter/smp.html) At the moment I've hacked all the console code to obtain the scheduler mutex instead of spltty()'ing all over the place, because in a word: it can't spltty() any more. It's illegal because the console code may be called at any time (see the next section). This is a hack because it isn't MP safe against tty interrupts running on another cpu. Since the current tty interrupt is a fast interrupt, I'm not sure that we're any worse off (fastints aren't masked by the cpl anyway). IMHO it explains why we need the proctree_lock (in early SMP times scheduler mutex). Maybe this should be replaced with a proper tty subsystem mutex ...) After looking at our SMPnewgen Page, Poul Henning and Thomas Moestel are working on locking the tty subsystem. I'll CC those :-) Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Crash with FreeBSD 6.1 STABLE of today
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?20041204110815.E80797 Something, somewhere is playing with t_session without locking... Any idea how we can track this down ? It's a very bad thing to have in 61. And yes, the serial output is going over a serial console. Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Crash with FreeBSD 6.1 STABLE of today
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) {
- sx_slock(proctree_lock);
if (tp-t_session-s_leader) {
struct proc *p;
p = tp-t_session-s_leader;
PROC_LOCK(p);
psignal(p, SIGHUP);
PROC_UNLOCK(p);
}
- sx_sunlock(proctree_lock);
}
+ sx_sunlock(proctree_lock);
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Crash with FreeBSD 6.1 STABLE of today
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 answer to this. There does seem to be a worrying comment above tty_close (which is the only place that t_session seems to be set to NULL): * XXX our caller should have done `spltty(); l_close(); tty_close();' * and l_close() should have flushed, but we repeat the spltty() and * the flush in case there are buggy callers. As I understand it, spltty() is now a no-op. Does this mean that this code is now essentially running without any locks that were used to serialise changes to struct tty in days gone by? Or is the whole tty subsystem still running under Giant? I thought this too. Maybe Robert knows more. Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Hardlock with Reboot option in beastie.4th
Hi, Yesterday I've installed 6.1. After rebooting, I got the beastie loader screen. I've typed 8 (reboot) to get into the raid bios again, but then the server freezed. Does this happen only to me or is it a common problem ? The server affected is a IBM 346 X-Series server with 2 CPUS. 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: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Crash with FreeBSD 6.1 STABLE of today
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 0xc06638b5 in panic (fmt=0xc0891732 %s) at
/usr/src/sys/kern/kern_shutdown.c:565
#3 0xc085c6b6 in trap_fatal (frame=0xed6e4ab8, eva=4) at
/usr/src/sys/i386/i386/trap.c:836
#4 0xc085c3bf in trap_pfault (frame=0xed6e4ab8, usermode=0, eva=4) at
/usr/src/sys/i386/i386/trap.c:744
#5 0xc085bfb5 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = -1063714776, tf_edi = -1064042304, tf_esi
= 0, tf_ebp = -311538944, tf_isp = -311538972, tf_ebx = -967615488, tf_edx =
-1063651212, tf_ecx = -941099136, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1066845359, tf_cs
= 32, tf_eflags = 66194, tf_esp = -967615488, tf_ss = 0})
at /usr/src/sys/i386/i386/trap.c:434
#6 0xc0848bea in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc0693b51 in ttymodem (tp=0xc6535c00, flag=-1063651212) at
/usr/src/sys/kern/tty.c:1659
#8 0xc0698362 in ptcclose (dev=0x0, flags=3, fmt=8192, td=0xc7e7f780) at
linedisc.h:136
#9 0xc0638a6f in giant_close (dev=0xcb3c1100, fflag=3, devtype=8192,
td=0xc7e7f780) at /usr/src/sys/kern/kern_conf.c:266
#10 0xc06162bf in devfs_close (ap=0xed6e4b7c) at
/usr/src/sys/fs/devfs/devfs_vnops.c:287
#11 0xc086dc1c in VOP_CLOSE_APV (vop=0x0, a=0xc099f874) at vnode_if.c:426
#12 0xc06c87e2 in vn_close (vp=0xc9cdf660, flags=3, file_cred=0x0,
td=0xc7e7f780) at vnode_if.h:227
#13 0xc06c974a in vn_closefile (fp=0xc6fc5438, td=0xc7e7f780) at
/usr/src/sys/kern/vfs_vnops.c:865
#14 0xc06162e7 in devfs_close_f (fp=0xc6fc5438, td=0xc7e7f780) at
/usr/src/sys/fs/devfs/devfs_vnops.c:297
#15 0xc0642cdc in fdrop_locked (fp=0xc6fc5438, td=0xc7e7f780) at file.h:295
#16 0xc0642c29 in fdrop (fp=0xc6fc5438, td=0xc7e7f780) at
/usr/src/sys/kern/kern_descrip.c:2122
#17 0xc06411c7 in closef (fp=0xc6fc5438, td=0xc7e7f780) at
/usr/src/sys/kern/kern_descrip.c:1942
#18 0xc063e329 in close (td=0xc7e7f780, uap=0x0) at
/usr/src/sys/kern/kern_descrip.c:1007
#19 0xc085c9f7 in syscall (frame=
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 0, tf_esi = 673925920,
tf_ebp = -1077941928, tf_isp = -311538332, tf_ebx = 673852332, tf_edx =
673925920, tf_ecx = 673925920,
tf_eax = 6, tf_trapno = 12, tf_err = 2, tf_eip = 673354727, tf_cs = 51,
tf_eflags = 518, tf_esp = -1077941956, tf_ss = 59}) at
/usr/src/sys/i386/i386/trap.c:981
#20 0xc0848c3f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200
#21 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
(kgdb) frame 5
#5 0xc085bfb5 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = -1063714776, tf_edi = -1064042304, tf_esi
= 0, tf_ebp = -311538944, tf_isp = -311538972, tf_ebx = -967615488, tf_edx =
-1063651212, tf_ecx =
-941099136, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1066845359, tf_cs
= 32, tf_eflags = 66194, tf_esp = -967615488, tf_ss = 0})
at /usr/src/sys/i386/i386/trap.c:434
(kgdb) frame 8
#8 0xc0698362 in ptcclose (dev=0x0, flags=3, fmt=8192, td=0xc7e7f780) at
linedisc.h:136
136 return ((*linesw[tp-t_line]-l_modem)(tp, flag));
(kgdb) list
131
132 static __inline int
133 ttyld_modem(struct tty *tp, int flag)
134 {
135
136 return ((*linesw[tp-t_line]-l_modem)(tp, flag));
137 }
138
139 #endif /* _KERNEL */
(kgdb) frame 7
(kgdb) p *tp-t_session
Cannot access memory at address 0x0
(kgdb) frame 7
#7 0xc0693b51 in ttymodem (tp=0xc6535c00, flag=-1063651212) at
/usr/src/sys/kern/tty.c:1659
1659if (tp-t_session-s_leader) {
(kgdb) list
1654!ISSET(tp-t_cflag, CLOCAL)) {
1655SET(tp-t_state, TS_ZOMBIE);
1656CLR(tp-t_state, TS_CONNECTED);
1657if (tp-t_session) {
1658sx_slock(proctree_lock);
1659if (tp-t_session-s_leader) {
1660struct proc *p;
1661
1662p = tp-t_session-s_leader;
1663PROC_LOCK(p);
(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 ?
Martin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Crash with FreeBSD 6.1 STABLE of today
Hi Robert and others, I just upgraded from 5.5 (stable btw.) to 6.1 and after 10 hours I got a nice panic. Does this look like some tty problem ? This is the machine which made that many problems with PREEMTION enabled in earlier releases of 5.x. Is it possible that I'm hitting now again the same bugs or is it clearly a tty related problem ? kgdb /var/core/kernel.debug /var/core/vmcore.6 #0 0xc0663002 in doadump () #1 0xc066355e in boot () #2 0xc06638b5 in panic () #3 0xc085c6b6 in trap_fatal () #4 0xc085c3bf in trap_pfault () #5 0xc085bfb5 in trap () #6 0xc0848bea in calltrap () #7 0xc0693b51 in ttymodem () #8 0xc0698362 in ptcclose () #9 0xc0638a6f in giant_close () #10 0xc06162bf in devfs_close () #11 0xc086dc1c in VOP_CLOSE_APV () #12 0xc06c87e2 in vn_close () #13 0xc06c974a in vn_closefile () #14 0xc06162e7 in devfs_close_f () #15 0xc0642cdc in fdrop_locked () #16 0xc0642c29 in fdrop () #17 0xc06411c7 in closef () #18 0xc063e329 in close () #19 0xc085c9f7 in syscall () #20 0xc0848c3f in Xint0x80_syscall () #21 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) 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 ? kgdb /var/core/kernel.debug /var/core/vmcore.6 kgdb: kvm_read: invalid address (0x21) kgdb: kvm_read: invalid address (0x21) kgdb: kvm_read: invalid address (0x21) kgdb: kvm_read: invalid address (0x21) kgdb: kvm_read: invalid address (0x21) kgdb: kvm_read: invalid address (0x21) kgdb: kvm_read: invalid address (0x21) kgdb: kvm_read: invalid address (0x21) kgdb: kvm_read: invalid address (0x21) kgdb: kvm_read: invalid address (0x21) kgdb: kvm_read: invalid address (0x21) kgdb: kvm_read: invalid address (0x21) kgdb: kvm_read: invalid address (0x21) kgdb: kvm_read: invalid address (0x21) kgdb: kvm_read: invalid address (0x21) kgdb: kvm_read: invalid address (0x21) kgdb: kvm_read: invalid address (0x21) kgdb: kvm_read: invalid address (0x21) kgdb: kvm_read: invalid address (0x21) kgdb: kvm_read: invalid address (0x21) kgdb: kvm_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: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.8 PR1 locks up for rm(1) big files
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 up. So this seems to be a scheduler and softupdates issue ! Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
HEADS UP: Broken if_dc NICs with MACs like 08:08[...] or 00:00[...]
*/
+ sc-dc_pmode == DC_PMODE_MII
+ ((txstat 0x) ~(DC_TXSTAT_ERRSUM|
+ DC_TXSTAT_NOCARRIER|DC_TXSTAT_CARRLOST)))
txstat = ~DC_TXSTAT_ERRSUM;
}
@@ -2553,11 +2649,13 @@
DC_INC(idx, DC_TX_LIST_CNT);
}
-if (idx != sc-dc_cdata.dc_tx_cons) {
+ if (idx != sc-dc_cdata.dc_tx_cons) {
+ /* some buffers have been freed */
sc-dc_cdata.dc_tx_cons = idx;
-ifp-if_flags = ~IFF_OACTIVE;
-}
-ifp-if_timer = (sc-dc_cdata.dc_tx_cnt == 0) ? 0 : 5;
+ ifp-if_flags = ~IFF_OACTIVE;
+ }
+ ifp-if_timer = (sc-dc_cdata.dc_tx_cnt == 0) ? 0 : 5;
+
return;
}
Index: if_dcreg.h
===
RCS file: /home/ncvs/src/sys/pci/if_dcreg.h,v
retrieving revision 1.4.2.20
diff -u -r1.4.2.20 if_dcreg.h
--- if_dcreg.h 5 Feb 2003 22:10:04 - 1.4.2.20
+++ if_dcreg.h 7 Feb 2003 19:01:18 -
@@ -688,13 +688,14 @@
u_int8_tdc_pmode;
u_int8_tdc_link;
u_int8_tdc_cachesize;
+ int dc_romwidth;
int dc_pnic_rx_bug_save;
unsigned char *dc_pnic_rx_buf;
int dc_if_flags;
int dc_if_media;
u_int32_t dc_flags;
u_int32_t dc_txthresh;
- u_int8_tdc_srom[1024];
+ u_int8_t*dc_srom;
struct dc_mediainfo *dc_mi;
struct dc_list_data *dc_ldata;
struct dc_chain_datadc_cdata;
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: finger -l [EMAIL PROTECTED]
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: double fault with vinum and 4.5 RC3
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 config file. Then create one drive per spindle, and choose your subdisk sizes to match what you want. Specifically, your config file should look like this: So why this isn't noted in the documentation ? Also the documentation is not up to date. vinum(4) still refers to raw disks etc. took da0 out and replaced it with a new disk. I switched jumpers, so da0 got da1, and da1 got da0 and rebooted. I still don't know why you're switching jumpers. That's not needed. But it doesn't change anything. Vinum still doesn't support booting from a vinum volume. If I do not switch jumpers, I'm not able to boot. I could also change the SCSI boot ID in the BIOS, but then FreeBSD cannot boot into Multiuser, since it cannot mount root from ad1s1a (it likes to do it from ad0s1a) And boom I got a double fault. Yes, we've found the cause of that. What I get now is: I'll look now it fixes my problem. Just rebooted and made new kernel. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: double fault with vinum and 4.5 RC3
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 providing a fix. We really should include this important fix in 4.5-Release. So I sent a copy to [EMAIL PROTECTED] too. Can you send them your fix too Greg ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: double fault with vinum and 4.5 RC3
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 should look like this: drive 0 device /dev/da0e drive 1 device /dev/da1e volume var setupstate plex org concat sd drive 0 len 2096000s plex org concat sd drive 1 len 2096000s volume docsis setupstate plex org concat sd drive 0 len 1257000s plex org concat sd drive 1 len 1257000s volume docsisvar setupstate plex org concat sd drive 0 len 4651000s plex org concat sd drive 1 len 4651000s Is this really mirrored ? I want a mirror, not a concatenated drive ! I want RAID 1. And - this isn't very optimal for a user to create. I do not want to calculate the sd offset size. I'm not a beginner with vinum, but I really do not want to do this. IMHO there should be a way for vinum to add this dynamically like: vinum sd-add -d 0 -n var -l 1GB vinum sd-add -d 0 -n docsis -l 6GB vinum sd-add -d 0 -n docsisvar -l end A program under unix does not have to be very cryptic, it also has to be userfriendly. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: double fault with vinum and 4.5 RC3
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 would be nice to find what it is. Possibly /dev/da1e would have worked. I tried first with /dev/da1e. Then I shought I should use /dev/da1s1e. No way. Errm, If it's allowed to ask, what is exactly the difference between the name with slice (s1e) and just the slice entry (e) ? I suppose I know what happened. da1 still had the vinum information stored at the same place as before from my three mirrors I made before. One time it worked, but vinum showed me a size of 1024m, exactly the size what /var was before. You see, da0s1e is exactly at the same place as the da0s1g with the new config ! I just did: - Removed the three slices da0s1e, da0s1f, da0s1g. - Removed the three slices da1s1e, da1s1f, da1s1g. - Made a big partiton on them. - Executed newfs on it. - Relabeled this partition as type vinum - Executed vinum create config and had the failure. Should be easy to find out what vinum does wrong here. Btw: I have a crash dump available for the race you said, it you are interested. If you login to the machine, there are also the log entries in /var/log/messages. Another thing I noted: newfs seems to make less superblock backups on big volumes now. Vinum still does make as many backups as FreeBSD did earlier for other filesystems. At least my experiments lead to some bug discovery ;) Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: NTPD dumps core in 4.5-PRERELEASE
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 CURRENT. drwxr-xr-x 2 root wheel 512 Dec 3 11:20 nwclient-6.0.2 Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: StarOffice woes on 4.4RC
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 Pratteln, Switzerland Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: 57E 7CCD 2769 E7AC C5FA DF2C 19C6 DCD1 1B3A EC9C -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
