/etc/rc's purgedir (or /etc/rc.d/cleanvar in 6.0)
Hello, I have a funny message at boot time, after fsck I see: real memory = 3489071104 (3407296K bytes) avail memory = 3394760704 (3315196K bytes) ... Mounting root from ufs:/dev/da0s1a pmap_collect: collecting pv entries -- suggest increasing PMAP_SHPGPERPROC pmap_collect: collecting pv entries -- suggest increasing PMAP_SHPGPERPROC maxproc limit exceeded by uid 0, please see tuning(7) and login.conf(5). maxproc limit exceeded by uid 0, please see tuning(7) and login.conf(5). em0: Link is up 100 Mbps Full Duplex I have traced this down to purgedir calling itself recursively while cleaning /var/run. In /var/run there is a dovecot-index directory, which seems to be 8 levels deep. I know that 8 levels deep is not normal, but it seems to me that purgedir() should be able to handle this, or am I overlooking something? Regards, Kai -- begin 600 .signature ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic: bundirty (nfs related)
options MAXDSIZ="(1024UL*1024*1024)" options MAXSSIZ="(1024UL*1024*1024)" options DFLDSIZ="(256UL*1024*1024)" options SMP makeoptions DEBUG=-g options INVARIANTS options INVARIANT_SUPPORT options DIAGNOSTIC Its running apache-1.3.37, serving pages from an NFS server (netapp) over nfs v3. Other mount options are: rw,bg,intr,resvport,nosuid. Anyone interested in helping me out? Regards, Kai -- This was an above the .signature production ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fatal trap 12: page fault while in kernel mode
On Wed, Apr 11, 2007 at 12:53:32PM +0200, Kai wrote:
>
> Hello all,
>
> We're running into regular panics on our webserver after upgrading
> from 4.x to 6.2-stable:
Hi Again,
The panics keep happening, so I'm trying alternate kernel setups. This is a
trace of a panic on a default SMP kernel with debugging symbols.
I'm At a loss on how to progress at this point, perhaps someone can help me
please?
System info:
uname -a reports FreeBSD webserver 6.2-RELEASE-p3 FreeBSD 6.2-RELEASE-p3 #0:
Thu Apr 19 11:37:34 CEST 2007 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/SMP
i386
Backtrace:
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x34
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc06bdefa
stack pointer = 0x28:0xeb9cf938
frame pointer = 0x28:0xeb9cf944
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 13577 (perl5.8.8)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 1h37m29s
Dumping 3070 MB (2 chunks)
chunk 0: 1MB (156 pages) ... ok
chunk 1: 3071MB (786016 pages) 3055 3039 3023 3007 2991 2975 2959 2943
2927 2911 2895 2879 2863 2847 2831 2815 2799 2783 2767 2751 2735 2719 2703
2687 2671 2655 2639 2623 2607 2591 2575 2559 2543 2527 2511 2495 2479 2463
2447 2431 2415 2399 2383 2367 2351 2335 2319 2303 2287 2271 2255 2239 2223
2207 2191 2175 2159 2143 2127 2111 2095 2079 2063 2047 2031 2015 1999 1983
1967 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743
1727 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503
1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263
1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023
1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735
719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447
431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159
143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc067550a in boot (howto=260) at ../../../kern/kern_shutdown.c:409
#2 0xc0675831 in panic (fmt=0xc08e46dd "%s")
at ../../../kern/kern_shutdown.c:565
#3 0xc088e29c in trap_fatal (frame=0xeb9cf8f8, eva=52)
at ../../../i386/i386/trap.c:837
#4 0xc088dfdb in trap_pfault (frame=0xeb9cf8f8, usermode=0, eva=52)
at ../../../i386/i386/trap.c:745
#5 0xc088dc15 in trap (frame=
{tf_fs = 8, tf_es = -606142424, tf_ds = -926089176, tf_edi =
#-605280928, tf_esi = -605280928, tf_ebp = -342034108, tf_isp = -342034140,
tf_ebx = -605280928, tf_edx = 4, tf_ecx = -926082048, tf_eax = 0, tf_trapno
#= 12, tf_err = 0, tf_eip = -1066672390, tf_cs = 32, tf_eflags = 66050,
tf_esp = -605280928, tf_ss = -605280928}) at ../../../i386/i386/trap.c:435
#6 0xc0879d4a in calltrap () at ../../../i386/i386/exception.s:139
#7 0xc06bdefa in vfs_vmio_release (bp=0xdbec2560) at atomic.h:146
#8 0xc06be728 in getnewbuf (slpflag=0, slptimeo=0, size=6585, maxsize=8192)
at ../../../kern/vfs_bio.c:1779
#9 0xc06bfccc in getblk (vp=0xca2cfdd0, blkno=8438, size=6585, slpflag=0,
slptimeo=0, flags=0) at ../../../kern/vfs_bio.c:2497
#10 0xc075ad41 in nfs_getcacheblk (vp=0xca2cfdd0, bn=8438, size=6585,
td=0xc8cd1c00) at ../../../nfsclient/nfs_bio.c:1261
#11 0xc075a978 in nfs_write (ap=0x0) at ../../../nfsclient/nfs_bio.c:1069
#12 0xc089fde6 in VOP_WRITE_APV (vop=0xc0984440, a=0xeb9cfbec)
at vnode_if.c:698
#13 0xc06dbb26 in vn_write (fp=0xc8940e10, uio=0xeb9cfcbc,
active_cred=0xc89ee880, flags=0, td=0xc8cd1c00) at vnode_if.h:372
#14 0xc0698f63 in dofilewrite (td=0xc8cd1c00, fd=5, fp=0xc8940e10,
auio=0xeb9cfcbc, offset=Unhandled dwarf expression opcode 0x93
) at file.h:252
#15 0xc0698e07 in kern_writev (td=0xc8cd1c00, fd=5, auio=0xeb9cfcbc)
at ../../../kern/sys_generic.c:402
#16 0xc0698d2d in write (td=0xc8cd1c00, uap=0xc8cd1c00)
at ../../../kern/sys_generic.c:326
#17 0xc088e5e3 in syscall (frame=
{tf_fs = 136970299, tf_es = 673775675, tf_ds = -1078001605, tf_edi =
#137019392, tf_esi = 673803768,
Re: Fatal trap 12: page fault while in kernel mode
On Thu, Apr 19, 2007 at 04:14:23PM +0200, Christian Walther wrote: > On 19/04/07, Kai <[EMAIL PROTECTED]> wrote: > >On Wed, Apr 11, 2007 at 12:53:32PM +0200, Kai wrote: > >> > >> Hello all, > >> > >> We're running into regular panics on our webserver after upgrading > >> from 4.x to 6.2-stable: > > > >Hi Again, > > > >The panics keep happening, so I'm trying alternate kernel setups. This is a > >trace of a panic on a default SMP kernel with debugging symbols. > > > >I'm At a loss on how to progress at this point, perhaps someone can help me > >please? > [snip] > > > >Fatal trap 12: page fault while in kernel mode > >cpuid = 0; apic id = 00 > >fault virtual address = 0x34 > >fault code = supervisor read, page not present > >instruction pointer = 0x20:0xc06bdefa > >stack pointer = 0x28:0xeb9cf938 > >frame pointer = 0x28:0xeb9cf944 > >code segment= base 0x0, limit 0xf, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > >processor eflags= interrupt enabled, resume, IOPL = 0 > >current process = 13577 (perl5.8.8) > >trap number = 12 > >panic: page fault > > Is this perl derived from ports? And if so, did you rebuild it after you > upgraded to 6.2? Or is maybe FreeBSD 4.x binary compatibility missing from > your kernel? Hi Chris, Thanks for your reply; The upgrade i'm talking about is just a term describing that we switched from FreeBSD 4.10 to 6.2. Its new hardware; its hardware on which FreeBSD 4.10 will not run. So in effect its not an upgrade, though the symptoms did not show on apache-1.3.37 + nfsmounted homepages under FreeBSD 4.10. If perl would be the problem, the OS shouldn't panic IMHO. Perl in this case is writing a fairly large guestbook file (eg. 2 Mb), and does this through perls own: open(BOOK, "+<$file") or die; This $file is located on an NFS mounted filesystem. It'll get read and written. The NFS filesystem is mounted with "rw,nosuid,intr,bg,resvport,nfsv3". I have tried mounting without intr, but panics keep happening. The NFS server is a Netapp filer. This is a production environment, so I can't go updating to the latest current. Kai -- This was an above the .signature production ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12: page fault while in kernel mode
On Thu, Apr 19, 2007 at 02:33:29PM +0200, Kai wrote: > On Wed, Apr 11, 2007 at 12:53:32PM +0200, Kai wrote: > > > > Hello all, > > > > We're running into regular panics on our webserver after upgrading > > from 4.x to 6.2-stable: > Hi all, To continue this story, a colleague wrote a small program in C that launches 40 threads to randomly append and write to 10 files on an NFS mounted filesystem. If I keep removing the files on one of the other machines in a while loop, the first system panics: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x34 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06bdefa stack pointer = 0x28:0xeb9f69b8 frame pointer = 0x28:0xeb9f69c4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 73626 (nfscrash) trap number = 12 panic: page fault cpuid = 1 Uptime: 3h2m14s Sounds like a nice denial of service problem. I can hand the program to developers on request. Regards, Kai Storbeck -- This was an above the .signature production ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006]
On Thu, 5 Jan 2006, Jo Rhett wrote: > > Look around. Every major commercial OS does it just fine. Most of the > open source OSes do it just fine. Debian had probably the easiest to use > system, and they've risen, owned the world and fallen all while FreeBSD has > been debating this issue. > Hello, Another ™.02, Today I'm installing Freebsd 6 from a CD, and I'm having to jump through loops to get it up-to-date. Take for example FreeBSD-SA-06:03.cpio. First I need to install the sources for the complete OS, then run a patch on it, and all that for the installation of 1 measily binary, and then keep track of the fact that I did this. Supplying kernel-source patches is fine, but IMHO there is something really wrong with this. I don't want to be bothered by the hassle of keeping track of which security update I patched in my sourcetree and which not. So, please pretty please make something that lets us admins just download a binary package for an updated cpio, and let something whine if its installed already on a system. Shouldn't be too big a problem to get this done in 2006, rpm could do the job, apt-get would suffice too? Regards, Kai -- begin 600 .signature ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 9.0 release - memstick installation fails
Hi list. Trying to install 9.0 release with a USB stick. I use FreeBSD-9.0-RELEASE-amd64-memstick.img At first the bootup looks promising, but in the end it stops with "Root mount waiting for: usbus2 usbus1 usbus" To single out a bad USB stick I tried FreeBSD-8.3-BETA1-amd64-memstick.img with the same stick and there are no problems. The hardware is an older HP/Compaq DL145-G3, but why toss it in the trash? How can I debug this further? Any hints? Kai. snip SMAP type=01 base= len=0009c000 SMAP type=02 base=0009c000 len=4000 SMAP type=02 base=000ce000 len=00032000 SMAP type=01 base=0010 len=dbe6 SMAP type=03 base=dbf6 len=7000 SMAP type=04 base=dbf67000 len=00019000 SMAP type=02 base=dbf8 len=0008 SMAP type=02 base=e000 len=1000 SMAP type=02 base=fec0 len=3000 SMAP type=02 base=fee0 len=1000 SMAP type=02 base=fff8 len=0008 SMAP type=01 base=0001 len=00012400 Table 'FACP' at 0xdbf62be7 Table 'SPMI' at 0xdbf66bf5 Table 'SSDT' at 0xdbf66c35 Table 'HPET' at 0xdbf66e7d Table 'SSDT' at 0xdbf66eb5 Table 'MCFG' at 0xdbf66efe Table 'SPCR' at 0xdbf66f3a Table 'APIC' at 0xdbf66f8a APIC: Found table at 0xdbf66f8a APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Table 'FACP' at 0xdbf62be7 Table 'SPMI' at 0xdbf66bf5 Table 'SSDT' at 0xdbf66c35 Table 'HPET' at 0xdbf66e7d Table 'SSDT' at 0xdbf66eb5 Table 'MCFG' at 0xdbf66efe Table 'SPCR' at 0xdbf66f3a Table 'APIC' at 0xdbf66f8a ACPI: No SRAT table found Preloaded elf kernel "/boot/kernel/kernel" at 0x813cf000. Calibrating TSC clock ... TSC clock: 2394059007 Hz CPU: Dual-Core AMD Opteron(tm) Processor 2216 HE (2394.06-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f13 Family = f Model = 41 Stepping = 3 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative real memory = 8589934592 (8192 MB) Physical memory chunk(s): 0x1000 - 0x00097fff, 618496 bytes (151 pages) 0x0010 - 0x001f, 1048576 bytes (256 pages) 0x01403000 - 0xdbf5, 3669348352 bytes (895837 pages) 0x0001 - 0x000213e45fff, 4628701184 bytes (1130054 pages) avail memory = 8244486144 (7862 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 x86bios: IVT 0x00-0x0004ff at 0xfe00 x86bios: SSEG 0x001000-0x001fff at 0xff800022 x86bios: EBDA 0x09c000-0x09 at 0xfe09c000 x86bios: ROM 0x0a-0x0fefff at 0xfe0a APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xf8510 00024 (v02 PTLTD ) ACPI: XSDT 0xdbf62b83 00064 (v01 PTLTD ? XSDT 0604 LTP ) ACPI: FACP 0xdbf62be7 00084 (v02 HP TREX 0604 MSFT 0201) ACPI: DSDT 0xdbf62c6b 03F8A (v01 HP TREX 0604 MSFT 0202) ACPI: FACS 0xdbf6ffc0 00040 ACPI: SPMI 0xdbf66bf5 00040 (v05 HP TREX 0604 PTL 0001) ACPI: SSDT 0xdbf66c35 00248 (v01 PTLTD POWERNOW 0604 LTP 0001) ACPI: HPET 0xdbf66e7d 00038 (v01 BRCM EXPLOSN 0604 BRCM 0201) ACPI: SSDT 0xdbf66eb5 00049 (v01 PTLTDSSDT 0604 AMD 0201) ACPI: MCFG 0xdbf66efe 0003C (v01 PTLTDMCFG 0604 AMD 0201) ACPI: SPCR 0xdbf66f3a 00050 (v01 PTLTD $UCRTBL$ 0604 PTL 0001) ACPI: APIC 0xdbf66f8a 00076 (v01 PTLTD
Re: FreeBSD 9.0 release - memstick installation fails
On Fri, 2012-03-02 Sean Bruno wrote: > You may want to try playing around with BIOS settings regarding USB. I'd happily do so, but unfortunately this BIOS.. PhoenixBIOS 4.0 Release 6.1 HP System BIOS - O09 (07/19/2007) HP FEATURES VERSION : 1.08.00 has no USB knobs to turn. Kai. > On Fri, 2012-03-02 at 13:01 -0800, Kai Gallasch wrote: >> Hi list. >> >> Trying to install 9.0 release with a USB stick. >> I use FreeBSD-9.0-RELEASE-amd64-memstick.img >> >> At first the bootup looks promising, but in the end it stops with "Root >> mount waiting for: usbus2 usbus1 usbus" >> >> To single out a bad USB stick I tried FreeBSD-8.3-BETA1-amd64-memstick.img >> with the same stick and there are no problems. >> >> The hardware is an older HP/Compaq DL145-G3, but why toss it in the trash? >> >> How can I debug this further? >> Any hints? >> >> Kai. >> >> >> snip >> >> SMAP type=01 base= len=0009c000 >> SMAP type=02 base=0009c000 len=4000 >> SMAP type=02 base=000ce000 len=00032000 >> SMAP type=01 base=0010 len=dbe6 >> SMAP type=03 base=dbf6 len=7000 >> SMAP type=04 base=dbf67000 len=00019000 >> SMAP type=02 base=dbf8 len=0008 >> SMAP type=02 base=e000 len=1000 >> SMAP type=02 base=fec0 len=3000 >> SMAP type=02 base=fee0 len=1000 >> SMAP type=02 base=fff8 len=0008 >> SMAP type=01 base=0001 len=00012400 >> Table 'FACP' at 0xdbf62be7 >> Table 'SPMI' at 0xdbf66bf5 >> Table 'SSDT' at 0xdbf66c35 >> Table 'HPET' at 0xdbf66e7d >> Table 'SSDT' at 0xdbf66eb5 >> Table 'MCFG' at 0xdbf66efe >> Table 'SPCR' at 0xdbf66f3a >> Table 'APIC' at 0xdbf66f8a >> APIC: Found table at 0xdbf66f8a >> APIC: Using the MADT enumerator. >> MADT: Found CPU APIC ID 0 ACPI ID 0: enabled >> SMP: Added CPU 0 (AP) >> MADT: Found CPU APIC ID 1 ACPI ID 1: enabled >> SMP: Added CPU 1 (AP) >> Copyright (c) 1992-2012 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >>The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 >> r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >> Table 'FACP' at 0xdbf62be7 >> Table 'SPMI' at 0xdbf66bf5 >> Table 'SSDT' at 0xdbf66c35 >> Table 'HPET' at 0xdbf66e7d >> Table 'SSDT' at 0xdbf66eb5 >> Table 'MCFG' at 0xdbf66efe >> Table 'SPCR' at 0xdbf66f3a >> Table 'APIC' at 0xdbf66f8a >> ACPI: No SRAT table found >> Preloaded elf kernel "/boot/kernel/kernel" at 0x813cf000. >> Calibrating TSC clock ... TSC clock: 2394059007 Hz >> CPU: Dual-Core AMD Opteron(tm) Processor 2216 HE (2394.06-MHz K8-class CPU) >> Origin = "AuthenticAMD" Id = 0x40f13 Family = f Model = 41 Stepping = 3 >> Features=0x178bfbff >> Features2=0x2001 >> AMD Features=0xea500800 >> AMD Features2=0x1f >> L1 2MB data TLB: 8 entries, fully associative >> L1 2MB instruction TLB: 8 entries, fully associative >> L1 4KB data TLB: 32 entries, fully associative >> L1 4KB instruction TLB: 32 entries, fully associative >> L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative >> L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way >> associative >> L2 2MB unified TLB: 0 entries, disabled/not present >> L2 4KB data TLB: 512 entries, 4-way associative >> L2 4KB instruction TLB: 512 entries, 4-way associative >> L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative >> real memory = 8589934592 (8192 MB) >> Physical memory chunk(s): >> 0x1000 - 0x00097fff, 618496 bytes (151 pages) >> 0x0010 - 0x001f, 1048576 bytes (256 pages) >> 0x01403000 - 0xdbf5, 3669348352 bytes (895837 pages) >> 0x0001 - 0x000213e45fff, 4628701184 bytes (1130054 pages) >> avail memory = 8244486144 (7862 MB) >> Event timer "LAPIC" quality 400 >> ACPI APIC Table: >> INTR: Adding local APIC 1 as a target >> FreeBSD/SMP: Multiproc
Re: FreeBSD 9.0 release - memstick installation fails
> Hi list. > > Trying to install 9.0 release with a USB stick. > I use FreeBSD-9.0-RELEASE-amd64-memstick.img > > At first the bootup looks promising, but in the end it stops with "Root mount > waiting for: usbus2 usbus1 usbus" Just for the records: Someone already had opened up a PR for this. http://www.freebsd.org/cgi/query-pr.cgi?pr=164773 Kai. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD 9.0 - BCE_JUMBO_HDRSPLIT kernel option for bce device still needed?
Hi. I found the comment below in an older 8.1 kernel config file. # BCE_JUMBO_HDRSPLIT # freebsd-curr...@freebsd.org/2009-11/msg00065.html # [The bce driver does not have a memory leak, # it does however have a bug which causes memory # fragmentation leading to denied mbuf allocation.] #=20 # You need to put "options BCE_JUMBO_HDRSPLIT" # In your kernel to enable the work arround. Is the kernel option BCE_JUMBO_HDRSPLIT still needed for a FreeBSD 9 kernel if you use the bce device (broadcom) ? I find it in the 9.0 kernel LINT file but it's not part of the GENERIC kernel. Kai.___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Fwd: FreeBSD 7.1 Content
-- Forwarded message --
From: Kai Otto <[EMAIL PROTECTED]>
Date: 2008/9/5
Subject: Re: FreeBSD 7.1 Content
To: Tom Evans <[EMAIL PROTECTED]>
Hello
I think someone mentioned it earlier, but I'm not shure.
IMHO it would _be_ nice if there's a HTML-browser in the standard
installation (with option to not install it in sysinstall).
I say HTML and not web because I think about the /usr/share/doc
.html-documentation. If someone really has no Internet-connection as
mentioned before he/she isn't able to read the handbook, which IMHO is a
very important part of FreeBSD. There are great manpages and exaple files,
but the best explanations are in the handbook.
Optional, the motd could tell the interested newbie how he/she can start
reading the handbook. At the moment, the standard motd explains how to learn
about manpages ('man man') and how to learn about the disklayout ('man
hier') that's just great.
An other way would be adding a hint to the shipped htmlbrowser (eg. lynx)
and it's initialisation with the handbook to the hier manpage.
I don't know if thats to 'deep hidden'.
An other thing was the problem with the outdated packages on the discset and
the people who need it because the 'target pc' for the install has no (or
only slow) internetconnection. I think this is already solved: People
needing up-to-date packages/ports can use the 'bootonly' iso-images and
download the complete installation from a local or internet server. The
other people can use the not-100%-up-to-date packages on the discset.
Greets, Kai
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: proliant server lockups with freebsd-amd64-stable (2010-03-10)
Am Fri, 12 Mar 2010 20:38:31 +0200
schrieb Alexander Motin :
> Pawel Jakub Dawidek wrote:
> > On Thu, Mar 11, 2010 at 01:39:16PM +0100, Kai Gallasch wrote:
> >> I have some trouble with an opteron server locking up
> >> spontaneously. It looses all networks connectivity and even
> >> through console I can get no shell.
> >>
> >> Lockups occur mostly under disk load (periodic daily, bacula backup
> >> running, make buildworld/buildkernel) and I can provoke them
> >> easily.
> > [...]
> >> 4 0 0 0 LL *cissmtx 0xff04ed820c00
> >> [g_down]
> > [...]
> >> 100046 L *cissmtx 0xff04ed820c00
> >> [irq257: ciss0]
> > [...]
> >
> > I was analizing similar problem as potential ZFS bug. It turned out
> > to be bug in ciss(4) and I believe mav@ (CCed) has fix for that.
>
> That my patch is already at 8-STABLE since r204873 of 2010-03-08. Make
> sure you have it.
Updating collection src-all/cvs
..
..
Edit src/sys/dev/ciss/ciss.c
Edit src/sys/dev/ciss/cissvar.h
Didn't have it! Must have been just a few hours I missed it,
when I built the last kernel. So I will rebuild my kernel and
give it a spin later on.
> In this case trap stopped process at ciss_get_request(), which indeed
> called holding cissmtx lock. But there is no place to sleep or loop
> there, so may be it was just spontaneous. With bugs I was fixing there
> was a chance to loop indefinitely between ciss and CAM on resource
> constraint. That increases chance for such situation to be caught.
>
> You may try also look what's going on with `top -HS` and `systat -vm
> 1`.
FYI. Without your patch of ciss.c and cissvar.h a lockup with top -HS
and systat -vm running gives following information below. Is there a
pattern visible relating to your patch of the ciss driver?
Kai.
-- vmstat -vm --
3 usersLoad 0.21 0.36 0.45 Mar 12 21:47
Mem:KBREALVIRTUAL VN PAGER SWAP PAGER
Tot Share TotShareFree in out in out
Act 2805456 40804 6269932079936 12358k count
All 6182560 95796 1136820k 212452 pages
Proc:Interrupts
r p d s w Csw Trp Sys Int Sof Fltcow 16018 total
491 533 28 576 19 179 174zfodatkbd0 1
ozfod uart0 irq4
12.9%Sys 12.5%Intr 0.1%User 0.0%Nice 74.5%Idle%ozfod ata0 irq14
||||||||||| daefr uhci0 45
==+++ prcfr 2000 cpu0: time
87 dtbuf totfr19 bce0 256
Namei Name-cache Dir-cache10 desvn react ciss0 257
Callshits %hits % 40811 numvn pdwak 2000 cpu1: time
17300 frevn pdpgs 2000 cpu4: time
intrn 2000 cpu5: time
Disks da0 da1 da2 da3 da4 pass0 pass1 4995516 wire 2000 cpu6: time
KB/t 0.00 0.00 0.00 0.00 0.00 0.00 0.00 2593276 act1999 cpu7: time
tps 0 0 0 0 0 0 0369560 inact 2000 cpu3: time
MB/s 0.00 0.00 0.00 0.00 0.00 0.00 0.00 9568 cache 2000 cpu2: time
%busy 0 0 0 0 0 0 0 12348752 free
1252272 buf
--- top -HS
last pid: 42561; load averages: 0.35, 0.38, 0.46up
0+11:24:36 21:53:39
658 processes: 13 running, 623 sleeping, 21 waiting, 1 lock
CPU: 0.6% user, 0.0% nice, 12.6% system, 25.0% interrupt, 61.8% idle
Mem: 2559M Active, 363M Inact, 4892M Wired, 9548K Cache, 1223M Buf, 12G Free
Swap: 21G Total, 21G Free
PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND
11 root 171 ki31 0K 128K CPU33 672:22 100.00% {idle: cpu3}
11 root 171 ki31 0K 128K CPU11 663:50 100.00% {idle: cpu1}
11 root 171 ki31 0K 128K RUN 4 649:18 100.00% {idle: cpu4}
12 root -32- 0K 384K CPU70 6:38 100.00% {swi4:
clock}
4 root -8- 0K16K CPU55 1:16 100.00% g_down
12 root -64- 0K 384K CPU20 1:15 100.00% {swi2:
cambio}
11 root 171 ki31 0K 128K CPU66 672:13 97.27% {idle: cpu6}
11 root 171 ki31 0K 128K CPU00 622:18 96.29% {idle: cpu0}
11 root 171 ki31 0K 128K RUN 7 676:57 10.99% {idle: cpu7}
2046 zope1 460 468M 379M ucond 6 7:30 1.76% {pyth
Re: proliant server lockups with freebsd-amd64-stable (2010-03-10)
> Am Fri, 12 Mar 2010 20:38:31 +0200 > schrieb Alexander Motin : > > > Pawel Jakub Dawidek wrote: > > > On Thu, Mar 11, 2010 at 01:39:16PM +0100, Kai Gallasch wrote: > > >> I have some trouble with an opteron server locking up > > >> spontaneously. It looses all networks connectivity and even > > >> through console I can get no shell. > > >> > > >> Lockups occur mostly under disk load (periodic daily, bacula > > >> backup running, make buildworld/buildkernel) and I can provoke > > >> them easily. > > > [...] > > >> 4 0 0 0 LL *cissmtx 0xff04ed820c00 > > >> [g_down] > > > [...] > > >> 100046 L *cissmtx 0xff04ed820c00 > > >> [irq257: ciss0] > > > [...] > > > > > > I was analizing similar problem as potential ZFS bug. It turned > > > out to be bug in ciss(4) and I believe mav@ (CCed) has fix for > > > that. > > > > That my patch is already at 8-STABLE since r204873 of 2010-03-08. > > Make sure you have it. Rebuilding the kernel with your 8-STABLE commited ciss patch seems to have resolved this issue. Server now has an uptime of 5 days and survives under high filesystem load. Alexander, thanks for fixing ciss. Kai. -- Da das Pferd pfluegt, lasst uns den Esel satteln. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD 9.1 - openldap slapd lockups, mutex problems
Hi. (Im am sending this to the "stable" list, because it maybe kernel related.. ) On 9.1-RELEASE I am witnessing lockups of the openldap slapd daemon. The slapd runs for some days and then hangs, consuming high amounts of CPU. In this state slapd can only be restarted by SIGKILL. # procstat -kk 71195 PIDTID COMM TDNAME KSTACK 71195 149271 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d do_wait+0x678 __umtx_op_wait+0x68 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 194998 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _cv_wait_sig+0x12e seltdwait+0x110 kern_select+0x6ef sys_select+0x5d amd64_syscall+0x546 Xfast_syscall+0xf7 71195 195544 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 196183 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_timedwait_sig+0x19 _sleep+0x2d4 userret+0x9e doreti_ast+0x1f 71195 197966 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 198446 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 198453 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 198563 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 199520 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 200038 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 200670 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 200674 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 200675 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 201179 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 201180 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 201181 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 201183 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 71195 201189 slapd-mi_switch+0x186 sleepq_catch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d _do_lock_umutex+0x5e8 do_lock_umutex+0x17c __umtx_op_wait_umutex+0x63 amd64_syscall+0x546 Xfast_syscall+0xf7 When I try to stop slapd through the rc script I can see in the logs that the process is waiting for a thread to terminate - indefinitely. Other multithreaded server processes running on the server without problems (apache-worker, mysqld, bind, etc.) On UFS2 slapd runs fine, without showing the error. Things I have tried already to stop the lockups: - running openldap-server23, openldap24 both with different BDB backend versions. - tuning the BDB Init File - reducin
Re: FreeBSD 9.1 - openldap slapd lockups, mutex problems
Am 22.01.2013 um 11:19 schrieb Kai Gallasch: > Hi. > > (Im am sending this to the "stable" list, because it maybe kernel related.. ) > > On 9.1-RELEASE I am witnessing lockups of the openldap slapd daemon. > > The slapd runs for some days and then hangs, consuming high amounts of CPU. > In this state slapd can only be restarted by SIGKILL. short update: I tried all I could to isolate the problem. What I am certain of is that the problem lies in the BDB backend for openldap itself, or how slapd interacts with it. My knowledge is not sufficient to debug BDB itself, it appears to be quite a complex gearbox. Also - as a sidenote - I had to learn that the new owner of BDB (orcle) does not give a toss about keeping old links to BDB documentation intact (for example informattion you'd need to tune your BDB - "DB_CONFIG" - or understand it better.) In the end I decided to drop the BDB backend for my running slapd installations and switch over to MDB[1,2] as backend and since then the problems disappeared. So if you are plagued by the same slapd lockups and rely on your ldap directory, switching backends will give you some peace of mind. Thanks to all who have replied! And thanks to sleepycat for all the fish. Kai Gallasch. [1] http://manpages.ubuntu.com/manpages/precise/man5/slapd-mdb.5.html [2] http://www.openldap.org/doc/admin24/backends.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
gptzfsboot: error 4 lba 30
Hi. On one of my fresh installed servers I am seeing the following output during boot: gptzfsboot: error 4 lba 30 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 30 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 gptzfsboot: error 4 lba 31 (Not shortened, exactly those lines) The server then manages to boot from a mirrored zpool. What is the cause of error 4 lba 30/31 ? - controller is a hp/compaq p400 (ciss) - da0 - da7 are raid0 volumes (controller not jbod capable) - freebsd 9.1 REL (same error message with 9-STABLE from 2013-03-24) - server is zfs-only # diskinfo -v da0 da0 512 # sectorsize 146778685440# mediasize in bytes (136G) 286677120 # mediasize in sectors 0 # stripesize 0 # stripeoffset 35132 # Cylinders according to firmware. 255 # Heads according to firmware. 32 # Sectors according to firmware. P61620D9SUP9ZS # Disk ident. # gpart show => 34 286677053 da0 GPT (136G) 342561 freebsd-boot (128k) 290 2866767972 freebsd-zfs (136G) => 34 286677053 da1 GPT (136G) 342561 freebsd-boot (128k) 290 2866767972 freebsd-zfs (136G) Could this be drive geometry releated? (The hp/compaq raid0 drive is just presented to the O/S and is not identical to the raw device, because of raidcontroller on-disk meta information) If I remember correctly the the hp raid configuration tool also offers the possibility to create raid0 drives with 63 sector geometry. Regards, Kai. --- dmesg --- Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Quad-Core AMD Opteron(tm) Processor 2389 (2900.17-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f42 Family = 10 Model = 4 Stepping = 2 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant real memory = 30064771072 (28672 MB) avail memory = 28952248320 (27611 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard ioapic2 irqs 32-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x920-0x923 on acpi0 pcib0: on acpi0 pcib0: Length mismatch for 4 range: 918 vs 917 pci0: on pcib0 vgapci0: port 0x1000-0x10ff mem 0xe800-0xefff,0xf7ff-0xf7ff irq 44 at device 3.0 on pci0 pci0: at device 4.0 (no driver attached) pci0: at device 4.2 (no driver attached) uhci0: port 0x1800-0x181f irq 45 at device 4.4 on pci0 usbus0 on uhci0 pci0: at device 4.6 (no driver attached) pcib1: at device 5.0 on pci0 pci1: on pcib1 pcib2: at device 13.0 on pci1 pci2: on pcib2 177,0x376,0x500-0x50f at device 6.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 isab0: at device 6.2 on pci0 isa0: on isab0 ohci0: port 0x1c00-0x1cff mem 0xf7ee-0xf7ee0fff irq 5 at device 7.0 on pci0 usbus1 on ohci0 ohci1: port 0x3000-0x30ff mem 0xf7ed-0xf7ed0fff irq 5 at device 7.1 on pci0 usbus2 on ohci1 ehci0: port 0x3400-0x34ff mem 0xf7ec-0xf7ec0fff irq 5 at device 7.2 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib3: irq 42 at device 15.0 on pci0 pci5: on pcib3 pcib4: irq 38 at device 16.0 on pci0 pci8: on pcib4 pcib5: irq 39 at device 17.0 on pci0 pci14: on pcib5 pcib6: irq 40 at device 18.0 on pci0 pci11: on pcib6 pcib7: irq 41 at device 19.0 on pci0 pci3: on pcib7 pcib8: at device 0.0 on pci3 pci4: on p
Re: gptzfsboot: error 4 lba 30
Am 02.04.2013 um 23:07 schrieb John Baldwin:
> On Monday, March 25, 2013 7:52:04 am Kai Gallasch wrote:
>> Hi.
>>
>> On one of my fresh installed servers I am seeing the following output during
> boot:
>>
>> gptzfsboot: error 4 lba 30
>> gptzfsboot: error 4 lba 31
>> gptzfsboot: error 4 lba 31
>> gptzfsboot: error 4 lba 31
>> gptzfsboot: error 4 lba 30
>> gptzfsboot: error 4 lba 31
>> gptzfsboot: error 4 lba 31
>> gptzfsboot: error 4 lba 31
>> gptzfsboot: error 4 lba 31
>> gptzfsboot: error 4 lba 31
>> gptzfsboot: error 4 lba 31
>> gptzfsboot: error 4 lba 31
>
> Humm, do you have disks that the BIOS sees that are small? An error code of 4
> means 'sector not found' or 'read error'. It would be interesting to see the
> output of 'lsdev -v' from the loader prompt.
Since upgrading the server to 9-STABLE (2013-03-30) the gptzfsboot error
message miraculously disappeared.
Because I upgraded the zpools on this particular server to a new version
("feature flags") I cannot boot back to 9.1-REL to find out if the upgrade was
the cause of this - or not.
When I bootup the server from a 9.1-REL USB stick, I also cannot reproduce the
error.
What did I change since seeing the error message the first time?
- I put GPT partitions on da2-da7 and used them for zpools
- Upgrading 9.1 REL to 9.1-2013-03-30
- refreshed the zfs bootcode on da0/da1 aferwards
If the error shows up again on a similar server soon to be upgraded, I'll give
feedback.
Kai.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Pass IGNORE_FILES to mergemaster in commandline
Am 01.10.2013 um 17:56 schrieb Łukasz Wąsikowski: > Hi all, > > How should I update config files in jails? I've always did it by running: > > IGNORE_FILES='/boot/device.hints /etc/motd' mergemaster -PFUi -D > /path/to/jail > > Now I'm getting *** FATAL ERROR: Unable to install ./boot/device.hints > to /path/to/jail/boot, so I assume that IGNORE_FILES is not used > anymore. I know, that the manual says that IGNORE_FILES can't be > overridden from commandline, but it worked. And it was good :) I'd > rather not want to go "edit /etc/mergemaster.rc" road, because I tend to > forget to change it back to defaults and it bitten me hard in the past. Hi. Putting e.g. IGNORE_FILES='/boot/device.hints /etc/motd /etc/hosts' in /etc/mergemaster.rc worked for me with 9.2-STABLE --Kai. -- GPG-Key: A593 E38B E968 4DBE 14D6 2115 7065 4D7C 4FB1 F588 Key available from hkps://hkps.pool.sks-keyservers.net PGP.sig Description: Signierter Teil der Nachricht
FreeBSD 10.1-RELENG - No serial console on Intel J1900
Hi list. For some time I have been struggling to get the serial console operational on an ASRock Q1900B-ITX mainboard (Intel J1900) I have "-Dh" in /boot.config and tried enabling ttyu0 and ttyu1 in /etc/ttys. Serial cable was connected to the onboads serial ports of the mainboard. What I also tried was connecting the serial console cable to a USB to serial converter (using ttyU0 device in /etc/ttys), but also no luck. When I press return on an active console session the cursor on the console does a carriage return to the next line, but the screen shows no output at all. This can be seen on the USB to serial converter cable connection and also on the connection to the serial ports on the mainboard. I also made a test with kern.vty=vt console="comconsole vidconsole" comconsole_speed="9600" boot_multicons="YES" in /boot/loader.conf - but no solution. Is this ACPI related? Any hint appreciated. Regards, K. --- pciconf -lv --- % pciconf -lv hostb0@pci0:0:0:0: class=0x06 card=0x0f311849 chip=0x0f008086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'ValleyView SSA-CUnit' class = bridge subclass = HOST-PCI vgapci0@pci0:0:2:0: class=0x03 card=0x0f311849 chip=0x0f318086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'ValleyView Gen7' class = display subclass = VGA ahci0@pci0:0:19:0: class=0x010601 card=0x0f231849 chip=0x0f238086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'ValleyView 6-Port SATA AHCI Controller' class = mass storage subclass = SATA xhci0@pci0:0:20:0: class=0x0c0330 card=0x0f351849 chip=0x0f358086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'ValleyView USB xHCI Host Controller' class = serial bus subclass = USB none0@pci0:0:26:0: class=0x108000 card=0x0f181849 chip=0x0f188086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'ValleyView SEC' class = encrypt/decrypt pcib1@pci0:0:28:0: class=0x060400 card=0x0f481849 chip=0x0f488086 rev=0x0c hdr=0x01 vendor = 'Intel Corporation' device = 'ValleyView PCI Express Root Port' class = bridge subclass = PCI-PCI pcib2@pci0:0:28:1: class=0x060400 card=0x0f4a1849 chip=0x0f4a8086 rev=0x0c hdr=0x01 vendor = 'Intel Corporation' device = 'ValleyView PCI Express Root Port' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:2: class=0x060400 card=0x0f4c1849 chip=0x0f4c8086 rev=0x0c hdr=0x01 vendor = 'Intel Corporation' device = 'ValleyView PCI Express Root Port' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:3: class=0x060400 card=0x0f4e1849 chip=0x0f4e8086 rev=0x0c hdr=0x01 vendor = 'Intel Corporation' device = 'ValleyView PCI Express Root Port' class = bridge subclass = PCI-PCI ehci0@pci0:0:29:0: class=0x0c0320 card=0x0f341849 chip=0x0f348086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'ValleyView USB Enhanced Host Controller' class = serial bus subclass = USB isab0@pci0:0:31:0: class=0x060100 card=0x0f1c1849 chip=0x0f1c8086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'ValleyView Power Control Unit' class = bridge subclass = PCI-ISA none1@pci0:0:31:3: class=0x0c0500 card=0x0f121849 chip=0x0f128086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'ValleyView SMBus Controller' class = serial bus subclass = SMBus re0@pci0:2:0:0: class=0x02 card=0x81681849 chip=0x816810ec rev=0x11 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet --- dmesg.out --- Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.1-RELEASE-p6 #0: Tue Feb 24 19:00:21 UTC 2015 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 VT: running with driver "vga". CPU: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz (2000.05-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x30673 Family = 0x6 Model = 0x37 Stepping = 3 Features=0xbfebfbff Features2=0x41d8e3bf AMD Features=0x28100800 AMD Features2=0x101 Structured Extended Features=0x2282 VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3790082048 (3614 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 cor
Re: Fatal trap 12: page fault while in kernel mode
Hi all,
Somewhere our IMAP software triggers this panic, and after some
searching on my part I've found this report: kern/113823
(http://www.freebsd.org/cgi/query-pr.cgi?pr=113823&cat=kern)
The software I am running is Dovecot serving IMAP to endusers and
webmail clients.
Perhaps one of the mutex hackers can dive into this problem, I can help
with more details if needed.
Kind regards,
Kai
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 06
fault virtual address = 0x104E
fault code = supervisor read, page not presentx
instruction pointer = 0x20:0xc0668f3dp
stack pointer = 0x28:0xe8916c70e
frame pointer = 0x28:0xe8916c7cn
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0s
current process = 9 (thread taskq)i
trap number = 12v
panic: page faulte
cpuid = 2
timeout(9) function: 0xc071a560(0) 0.028705867 s
Uptime: 2d20h58m42s
Dumping 3327 MB (2 chunks)
chunk 0: 1MB (154 pages) ... ok
chunk 1: 3327MB (851568 pages) 3311 3295 3279 3263 3247 3231 3215
3199 3183 3167 3151 3135 3119 3103 3087 3071 3055 3039 3023 3007 2991
2975 2959 2943 2927 2911 2895 2879 2863 2847 2831 2815 2799 2783 2767
2751 2735 2719 2703 2687 2671 2655 2639 2623 2607 2591 2575 2559 2543
2527 2511 2495 2479 2463 2447 2431 2415 2399 2383 2367 2351 2335 2319
2303 2287 2271 2255 2239 2223 2207 2191 2175 2159 2143 2127 2111 2095
2079 2063 2047 2031 2015 1999 1983 1967 1951 1935 1919 1903 1887 1871
1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647
1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423
1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199
1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959
943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671
655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383
367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95
79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc0670918 in boot (howto=260) at ../../../kern/kern_shutdown.c:409
#2 0xc0670bfa in panic (fmt=0xc08d0a0d "%s")
at ../../../kern/kern_shutdown.c:565
#3 0xc087819c in trap_fatal (frame=0xe8916c30, eva=260)
at ../../../i386/i386/trap.c:837
#4 0xc087794a in trap (frame=
{tf_fs = -393150456, tf_es = -1064959960, tf_ds = -393150424,
tf_edi = -935090688, tf_esi = -900488032, tf_ebp = -393122692, tf_isp =
-393122724, tf_ebx = 4, tf_edx = 6, tf_ecx = 2, tf_eax = 1, tf_trapno =
12, tf_err = 0, tf_eip = -1067020483, tf_cs = 32, tf_eflags = 65538,
tf_esp = 1714, tf_ss = -1064340051})
at ../../../i386/i386/trap.c:270
#5 0xc08649ea in calltrap () at ../../../i386/i386/exception.s:139
#6 0xc0668f3d in _mtx_lock_sleep (m=0xca53a4a0, tid=3359876608, opts=0,
file=0xc08f75ad "../../../kern/uipc_usrreq.c", line=1714)
at ../../../kern/kern_mutex.c:546
#7 0xc0668b93 in _mtx_lock_flags (m=0x2, opts=0,
file=0xc08f75ad "../../../kern/uipc_usrreq.c", line=1714)
at ../../../kern/kern_mutex.c:288
#8 0xc06b204b in unp_gc (arg=0x0, pending=1)
at ../../../kern/uipc_usrreq.c:1714
#9 0xc068f7c0 in taskqueue_run (queue=0xc843ca80)
at ../../../kern/subr_taskqueue.c:257
#10 0xc068fb3e in taskqueue_thread_loop (arg=0x1)
at ../../../kern/subr_taskqueue.c:376
#11 0xc065d184 in fork_exit (callout=0xc068faf4 ,
arg=0xc09df4e8, frame=0xe8916d38) at ../../../kern/kern_fork.c:821
#12 0xc0864a4c in fork_trampoline () at ../../../i386/i386/exception.s:208
(kgdb)
--
This was an above the .signature production
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
LSI SAS2008 mps driver preferred firmware version
Hi. I'm currently building a new ZFS based FreeBSD 10.2 server with a SAS/SATA HBA SAS9211-8i. Is there a preferred or recommended firmware version for Fusion-MPT SAS-2 2008 chipset based LSI cards like the SAS9211-8i? MPS(4) does not give any information about this. The current version of my SAS9211-8i is: v7.05.05.00 (2010.05.19), BIOS 5.00.17.00-IR, FW IR vs. IT firmware: Are there any advantages replacing the -IR (integrated raid) firmware on the LSI controller with an -IT (target mode) version, if the RAID functionality of the HBA is not used at all? There were some claims that running the -IR version in a ZFS JBOD setup would result in a small performance penalty compared to -IT and that there was a risk that a controller running the -IR firmware version could potentially damage ZFS data on a disk by putting RAID metadata somewhere on the drive, even if not using the RAID feature of the card! I'd appreciate it if someone could shed some light on this. Regards, Kai. -- PGP-KeyID = 0x70654D7C4FB1F588 One day a lemming will fly.. signature.asc Description: OpenPGP digital signature
Re: LSI SAS2008 mps driver preferred firmware version
On 12.11.2015 23:20 Royce Williams wrote: > Firmware should match driver, e.g.: > > mps0: Firmware: 19.00.00.00, Driver: 19.00.00.00-fbs > > > Some of this may help -- not yet updated for 10.2, but may still be useful: > > http://roycebits.blogspot.com/2015/01/freebsd-lsi-sas9211-8i-hba-firmware.html Thanks! Lots of information about reflashing the 9211-8i. So I upgraded the old firmare of the controller from mps0: Firmware: 05.00.17.00, Driver: 20.00.00.00-fbsd to mps0: Firmware: 20.00.04.00, Driver: 20.00.00.00-fbsd (FreeBSD 10.2) As I understand it the firmware 20.00.00.00 was pulled by avago and replaced with the fixed version 20.00.04.00 I will give feedback if I notice any problems with this FW version. As a side note: Flashing the 9211-8i to the new firmware version changed the way FreeBSD orders the disk devices on this server: With the old firmware it looked like this: root@:~ # camcontrol devlist at scbus0 target 10 lun 0 (pass0,da0) at scbus0 target 11 lun 0 (pass1,da1) at scbus0 target 12 lun 0 (pass2,da2) at scbus0 target 13 lun 0 (pass3,da3) at scbus0 target 14 lun 0 (pass4,da4) at scbus0 target 15 lun 0 (pass5,da5) at scbus0 target 16 lun 0 (pass6,da6) at scbus0 target 17 lun 0 (pass7,da7) at scbus0 target 18 lun 0 (pass8,da8) at scbus0 target 19 lun 0 (pass9,da9) at scbus0 target 20 lun 0 (pass10,da10) at scbus0 target 21 lun 0 (pass11,da11) at scbus0 target 22 lun 0 (pass12,ses0) at scbus7 target 0 lun 0 (pass13,ses1) The order is according to the order the disks are placed in the drive bays: (da0, bay1; da1, bay2, ..) With the new firmware it now looks like this: at scbus0 target 8 lun 0 (pass0,da0) at scbus0 target 9 lun 0 (pass1,da1) at scbus0 target 10 lun 0 (pass2,da2) at scbus0 target 11 lun 0 (pass3,da3) at scbus0 target 12 lun 0 (pass4,da4) at scbus0 target 13 lun 0 (pass5,da5) at scbus0 target 14 lun 0 (pass6,da6) at scbus0 target 15 lun 0 (pass7,da7) at scbus0 target 16 lun 0 (pass8,da8) at scbus0 target 17 lun 0 (pass9,da9) at scbus0 target 18 lun 0 (pass10,da10) at scbus0 target 19 lun 0 (pass11,da11) at scbus0 target 20 lun 0 (pass12,ses0) at scbus7 target 0 lun 0 (pass13,ses1) So now the drive stuck in the last drive bay is seen as da0 and the drive in the first drive bay as da11 But: In the controller BIOS the scan order of the drives did not change at all with the new firmware! So the change is only in the way FreeBSD sees the drives. My explanation for this change in drive ordering is, that my 9211-8i is a SUN branded one (SGX-SAS6-INT-Z) and the server is a SUN server. So maybe the original firmware contained some adaptations for this server, that are missing in the new firmware. Can the way FreeBSD orders scanned SAS drives be changed? If not, no problem, as I use partition labels for my zfs pools and the disks are also labeled on the server as well. Regards, Kai. -- PGP-KeyID = 0x70654D7C4FB1F588 One day a lemming will fly.. signature.asc Description: OpenPGP digital signature
Re: FreeBSD Quarterly Status Report - Fourth Quarter 2016
On 14.02.2017 05:20 Benjamin Kaduk wrote: > Core requested the removal of the misc/jive port, on the grounds that >it had no function other than to turn text into an offensively racist >parody. This proved controversial, with many seeing this as a first >step in bowdlerizing the entire ports tree. That is certainly not >Core's intention. Core's aim here is to help secure the future of the >FreeBSD project by making it welcoming to all contributors, regardless >of ethnicity, gender, sexuality or other improper bases for >discrimintation. While misc/jive may once have been seen as harmless >fun, today the implicit approval implied by having it in the ports tree >sends a message at odds with the project's aims. Am I dreaming? Has this "disease" finally reached my beloved FreeBSD after all this years? In my opinion it is just not Cores business making decisions besides the technical and organizational aspect. As long as any port has a handful of users and someone is willing to support it, its existence in the tree is justified. And basically I don't care if there is a port in the tree, where little harmless kittens are being shot at. Thank you Core! You made my day! K. signature.asc Description: OpenPGP digital signature
Re: bus_dmamem_alloc in drm / radeon
I am having nearly the same problem. I startx and the machine ether hangs or kernel panics. I tried to look at the crash dumps but I am no expert will kgdb. Brian A. Seklecki wrote: A highly repeatable situation: FreeBSD soundwave 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0: Wed Sep 13 14:51:18 EDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP i386 drm0: port 0xdd00-0xddff mem 0xf000-0xf7ff,0xfe9e-0xfe9e irq 22 at device 1.0 on pci2 info: [drm] Initialized radeon 1.24.0 20060225 info: [drm] Setting GART location based on old memory map * bus_dmamem_alloc failed to align memory properly.info: [drm] Loading R200 Microcode info: [drm] writeback test succeeded in 1 usecs The Xorg process goes solid in ioctl on /dev/dri/card0 presumably 768 seklecki 1 1280 149M 10516K RUN 4:56 100.15% Xorg 768 Xorg CALL ioctl(0x8,0x20006444 ,0) 768 Xorg RET ioctl -1 errno 16 Device busy 768 Xorg CALL ioctl(0x8,0x20006444 ,0) 768 Xorg RET ioctl -1 errno 16 Device busy 768 Xorg CALL ioctl(0x8,0x20006444 ,0) 768 Xorg RET ioctl -1 errno 16 Device busy 768 Xorg CALL ioctl(0x8,0x20006444 ,0) 768 Xorg RET ioctl -1 errno 16 Device busy 768 Xorg CALL ioctl(0x8,0x20006444 ,0) 768 Xorg RET ioctl -1 errno 16 Device busy 768 Xorg CALL ioctl(0x8,0x20006444 ,0) 768 Xorg RET ioctl -1 errno 16 Device busy 768 Xorg CALL ioctl(0x8,0x20006444 ,0) I can provide full dmesg(8) if needed. l8* -lava (Brian A. Seklecki - Pittsburgh, PA, USA) http://www.spiritual-machines.org/ "...from back in the heady days when "helpdesk" meant nothing, "diskquota" meant everything, and lives could be bought and sold for a couple of pages of laser printout - and frequently were." ___ 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: FreeBSD 6.2-STABLE and Flash 7 patch
This is a Firefox specific patch which requires the rtld be patched. Many thanks to those who have provided patch updates because I was at a lost without them. Oliver Fromme wrote: [EMAIL PROTECTED] wrote: > Torfinn Ingolfsen wrote: > > BTW, what is the reason this "hack" isn't included in the base kernel > > / code? > > Because it is probably unnecessary? I run a recent 6-STABLE and use > the flash7 plugin *without* this patch. I am using Opera, though, not > Firefox... Same here. I use Opera with the Flash plugin on 6-STABLE without any problems. I haven't applied a patch to rtld. Best regards Oliver ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0: ath_reset: unable to reset hardware; hal status 3
Hello, I am having the same type of trouble with a Dynex card. I mearly receive 'ath0: Device timeout' on the main console screen. > I take it you tried ifconfig'ing the interface down and up? I have. The card does not appear to reset itself. While the card is up, it just rotates across the chanels. > The output of athstats at the point where things are wedged might be > useful. # /usr/local/bin/athstats 84874 data frames received 53228 data frames transmit 2228 tx frames with an alternate rate 15357 long on-chip tx retries 560 tx failed 'cuz too many retries 98877 mib overflow interrupts 11M current transmit rate 860 watchdog timeouts 85 beacon miss interrupts 612 tx management frames 1602 tx frames discarded prior to association 496 tx frames with no ack marked 21148 rx failed 'cuz of bad CRC 361 rx failed 'cuz of PHY err 96 OFDM restart 265 CCK restart 13422 periodic calibrations 10 rssi of last ack -95 rx noise floor 18 phantom beacon misses 1 rx failed 'cuz frame too large 1 switched default/rx antenna Antenna profile: [1] tx51420 rx 1829072 [2] tx 403 rx 116 # > Also verify if only tx is wedged (e.g. athstats 1 will show you > if you're receiving frames). input output altrate shortlong xretry crcerr crypt phyerr rssi rate 84874532282228 0 15357560 21148 0 3610 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M The above snippet repeats verbatium regardless of traffic. > Best suggestion I can make is to use a > different model card. I can't. Is there someway to look into this issue deeper? Thanks, Kai Lockwood ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: openssh root hole?
Lauri Laupmaa wrote: > > As I just read from http://www.pine.nl/advisories/pine-cert-20020301.txt > OpenSSH All versions between 2.0 and 3.0.2 have local root hole. > Is it fixed in -STABLE or is it issue at all? I just cvsup'ed -STABLE and the announced fix was already applied to /usr/src/crypto/openssh/channels.c Happy compiling, Kai -- dreiecksplatz 8, d-24105 kiel, +49-431-22199869, http://k.123.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: killing sendmail on boot
Rasputin wrote:
>
> Right, what do I need to specify in rc.conf to
> stop sendmail completely?
>
> I have:
>
> sendmail_enable="NONE"# Run the sendmail inbound daemon (YES/NO).
> #sendmail_outbound_enable="NO"# Dequeue stuck mail (YES/NO).
> #sendmail_msp_queue_enable="NO" # Dequeue stuck clientmqueue mail (YES/NO).
> #sendmail_submit_enable="NO" # Start a localhost-only MTA for mail submission
>
> Do I need to uncomment anything else? This is a buttload of noise for
> a service I don't have installed (not that I want to resurrect *that* thread).
Take a look into /etc/rc
case ${sendmail_enable} in
[Yy][Ee][Ss])
echo -n ' sendmail'
/usr/sbin/sendmail ${sendmail_flags}
;;
*)
case ${sendmail_outbound_enable} in
[Yy][Ee][Ss])
echo -n ' sendmail'
/usr/sbin/sendmail ${sendmail_outbound_flags}
;;
esac
;;
esac
So, set both sendmail_enable and sendmail_outbound_enable to NO to
completely disable any call to sendmail.
Kai
--
dreiecksplatz 8, d-24105 kiel, +49-431-22199869, http://k.123.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: Multiple IP addresses
Jim Manley wrote: > Found it. Syntax problem. > > ifconfig alias 192.168.0.10 netmask 0x And to get all this done automatically at boot time, add this to your /etc/rc.conf network_interfaces="de0 lo0" # List of network interfaces (lo0 is loopback). ifconfig_de0="inet 195.244.241.123 netmask 255.255.255.0" ifconfig_de0_alias0="inet 195.244.241.124 netmask 255.255.255.255" ifconfig_de0_alias1="inet 195.244.241.125 netmask 255.255.255.255" ifconfig_de0_alias2="inet 195.244.241.126 netmask 255.255.255.255" ifconfig_de0_alias3="inet 195.244.241.127 netmask 255.255.255.255" ifconfig_de0_alias4="inet 195.244.241.128 netmask 255.255.255.255" Kai PS: People, please learn to quote, thank you. -- kai voigt hamburger chaussee 36 24113 kiel 04 31 - 22 19 98 69 http://k.123.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Previous Message on /etc/defaults
On Mon, 10 Jul 2000, Jonathan Smith wrote: > The reason against it is that it makes it harder to go through and > configure a fresh system. As I had said, one of my favorite things > was to have one file to go through and change what I needed to. There are two approaches: (1) Copy /etc/defaults/rc.conf to /etc/rc.conf, edit /etc/rc.conf and delete all unchanged lines from it. (Here, the extra step is to delete the unchanged lines. If most lines are unchanged, the second approach might be better.) (2) Open two windows, one looking at the /etc/defaults/rc.conf and a text editor looking at an empty /etc/rc.conf. Copy and paste all lines from /etc/defaults/rc.conf into /etc/rc.conf and change as appropriate. Of course, the first time you do this it is more work. But considering that you can just keep /etc/rc.conf and don't have to merge in the changes, this work is saved the next time you update. kai -- I like BOTH kinds of music. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: amd64/71644: amd64 5.3-BETA4 crash when heavy load
On Sun, Nov 28, 2004 at 11:16:39PM +0800, Xin LI wrote: > Hmm... Is it possible to obtain a backtrace (bt full under kgdb) and post > it? > Additionally I suggest that you post the same thing to -stable@ and cc to > rwatson@, along with your dmesg.boot (verberose perferred). Here is the panic messages: (If this is not what you want, could you tell me what I shall do? thanks!) Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x18 fault code= supervisor read, page not present instruction pointer = 0x8:0x8026ece0 stack pointer = 0x10:0xd2d6f8b0 frame pointer = 0x10:0xd2d6f920 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 46 (swi1: net) [thread 100025] Stopped at m_copym+0x40:incl %ebp db> trace m_copym() at m_copym+0x40 tcp_output() at tcp_output+0xdf1 tcp_input() at tcp_input+0x1d2b netisr_processqueue() at netisr_processqueue+0xd2 swi_net() at swi_net+0x13c ithread_loop() at ithread_loop+0x1b8 fork_exit() at fork_exit+0xaa fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffd2d6fd00, rbp = 0 --- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mod_php4 won't compile for Apache 2.0.39
I just cvsuped and updated apache2 to 2.0.39 when I cd /usr/ports/www/mod_php4/ make -DWITH_APACHE2I get the following errors: -I/usr/ports/www/mod_php4/work/php-4.2.1/TSRM -I/usr/local/include/pth -O -pipe -I/usr/local/include -pthread -DZTS -prefer-pic -c php_functions.cphp_functions.c:93: syntax error*** Error code 1 Stop in /usr/ports/www/mod_php4/work/php-4.2.1/sapi/apache2filter.*** Error code 1 Stop in /usr/ports/www/mod_php4/work/php-4.2.1/sapi/apache2filter.*** Error code 1 Stop in /usr/ports/www/mod_php4/work/php-4.2.1/sapi.*** Error code 1 Stop in /usr/ports/www/mod_php4/work/php-4.2.1.*** Error code 1 Stop in /usr/ports/www/mod_php4.*** Error code 1 Stop in /usr/ports/www/mod_php4.
mod_php4 won't compile for Apache2 2.0.39
I just cvsuped and updated apache2 to 2.0.39 when I cd /usr/ports/www/mod_php4/ make -DWITH_APACHE2I get the following errors: -I/usr/ports/www/mod_php4/work/php-4.2.1/TSRM -I/usr/local/include/pth -O -pipe -I/usr/local/include -pthread -DZTS -prefer-pic -c php_functions.cphp_functions.c:93: syntax error*** Error code 1 Stop in /usr/ports/www/mod_php4/work/php-4.2.1/sapi/apache2filter.*** Error code 1 Stop in /usr/ports/www/mod_php4/work/php-4.2.1/sapi/apache2filter.*** Error code 1 Stop in /usr/ports/www/mod_php4/work/php-4.2.1/sapi.*** Error code 1 Stop in /usr/ports/www/mod_php4/work/php-4.2.1.*** Error code 1 Stop in /usr/ports/www/mod_php4.*** Error code 1 Stop in /usr/ports/www/mod_php4.
