Re: FreeBSD -STABLE servers repeatedly crashing.
On Tue, 12 Jul 2005, Matt Juszczak wrote: So far a 13 day up time after switching from IPF to PF. If thats not the problem, I hope I find it soon considering this is a production server ... but it seems to be more stable. For me, 5 days up time after switching from IPF to PF. Before the switch a couple of hours of uptime was the maximum. Seems like the crashes are caused by ipfilter. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD -STABLE servers repeatedly crashing.
Could you try SMP kernel without IPF support and without using IPF module? Could you confirm, that your SMP kernel is not crashing when you do not use IPF? Interesting that the box has survived almost two days now, while it was always crashing after at least 8 hours. Anyway, I have compiled a new kernel without ipfilter, I have used pf instead (the configuration changes from ipfilter to pf were mostly minor). We'll see how long the box survives now. Blaz Zupan, Medinet d.o.o, Trzaska 85, SI-2000 Maribor, Slovenia E-mail: [EMAIL PROTECTED], Tel: +386 2 320 6320, Fax: +386 2 320 6325 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD -STABLE servers repeatedly crashing.
In order for this problem to not get lost on the freebsd-stable mailing list, I have opened a PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=83220 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD -STABLE servers repeatedly crashing.
On Wed, 6 Jul 2005, Kris Kennaway wrote: That should be OK as long as you're not cross-compiling for different architectures. No, we only have i386 boxes. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD -STABLE servers repeatedly crashing.
On Wed, 6 Jul 2005, Kris Kennaway wrote: Interesting, this seems to finger the TCP code. Are you compiling your kernel with -O2 though (this causes bogus stack frames like you have here)? If so, recompile with -O and try to obtain another trace. Nope, no funky compile options, all at the default. The only "weird" thing I'm doing is that the world is built on a 4.11 box and is shared between all our boxes, so that we don't need to compile multiple times. The kernel config is here: machine i386 cpu I686_CPU ident DL380 options SCHED_4BSD # 4BSD scheduler options INET# InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options GEOM_GPT# GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options NMBCLUSTERS=12000 options IPFILTER options IPFILTER_LOG options SMP options INCLUDE_CONFIG_FILE options KDB_STOP_NMI options KDB options DDB makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols device apic# I/O APIC device isa device eisa device pci device fdc device ata device atapicd # ATAPI CDROM drives options ATA_STATIC_ID # Static device numbering device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device ciss# Compaq Smart RAID 5* device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device sc device agp # support several AGP chipsets device npx device pmtimer device sio # 8250, 16[45]50 based serial ports device miibus # MII bus support device bge # Broadcom BCM570xx Gigabit Ethernet device loop# Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device bpf # Berkeley packet filter device ohci# OHCI PCI->USB interface device usb # USB Bus (required) device ukbd# Keyboard device ums # Mouse ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD -STABLE servers repeatedly crashing.
On Wed, 6 Jul 2005, Kris Kennaway wrote:
Please obtain the backtrace with kgdb.
Here you go:
[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".
#0 doadump () at pcpu.h:159
159 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:159
#1 0xc044b006 in db_fncall (dummy1=0, dummy2=0, dummy3=-1067606609, dummy4=0xe4b6c9d0
"üÉśä(\205]ŔčÉśäěÉśä\222\a")
at /usr/src5/sys/ddb/db_command.c:531
#2 0xc044ae14 in db_command (last_cmdp=0xc0674644, cmd_table=0x0,
aux_cmd_tablep=0xc064226c, aux_cmd_tablep_end=0xc0642270)
at /usr/src5/sys/ddb/db_command.c:349
#3 0xc044aedc in db_command_loop () at /usr/src5/sys/ddb/db_command.c:455
#4 0xc044ca75 in db_trap (type=12, code=0) at /usr/src5/sys/ddb/db_main.c:221
#5 0xc04e6599 in kdb_trap (type=12, code=0, tf=0xe4b6cb3c) at
/usr/src5/sys/kern/subr_kdb.c:468
#6 0xc05f4c79 in trap_fatal (frame=0xe4b6cb3c, eva=36) at
/usr/src5/sys/i386/i386/trap.c:812
#7 0xc05f43e9 in trap (frame=
{tf_fs = -1040580584, tf_es = -1029439472, tf_ds = 16, tf_edi =
-1038000128, tf_esi = -1066898900, tf_ebp = -457782384, tf_isp = -457782424,
tf_ebx = -1040530304, tf_edx = -1040524364, tf_ecx = -1040524544, tf_eax = 0,
tf_trapno = 12, tf_err = 0, tf_eip = -1068574101, tf_cs = 8, tf_eflags = 65683,
tf_esp = 180, tf_ss = 0}) at /usr/src5/sys/i386/i386/trap.c:255
#8 0xc05e283a in calltrap () at /usr/src5/sys/i386/i386/exception.s:140
#9 0xc1fa0018 in ?? ()
#10 0xc2a40010 in ?? ()
#11 0x0010 in ?? ()
#12 0xc2216000 in ?? ()
#13 0xc0686a2c in tcbinfo ()
#14 0xe4b6cb90 in ?? ()
#15 0xe4b6cb68 in ?? ()
#16 0xc1fac480 in ?? ()
#17 0xc1fadbb4 in ?? ()
#18 0xc1fadb00 in ?? ()
#19 0x in ?? ()
#20 0x000c in ?? ()
#21 0x in ?? ()
#22 0xc04eda6b in propagate_priority (td=0xc2216000) at
/usr/src5/sys/kern/subr_turnstile.c:243
#23 0xc04ee225 in turnstile_wait (ts=0xc1fadb00, lock=0xc0686a2c,
owner=0xc2216000)
at /usr/src5/sys/kern/subr_turnstile.c:556
#24 0xc04c5ced in _mtx_lock_sleep (m=0xc0686a2c, td=0xc1fac480, opts=0,
file=0x0, line=0)
at /usr/src5/sys/kern/kern_mutex.c:552
#25 0xc0559ad8 in tcp_usr_rcvd (so=0x0, flags=0) at
/usr/src5/sys/netinet/tcp_usrreq.c:602
#26 0xc0506103 in soreceive (so=0xc27bf798, psa=0x0, uio=0xe4b6cc88, mp0=0x0,
controlp=0x0, flagsp=0x0)
at /usr/src5/sys/kern/uipc_socket.c:1395
#27 0xc04f4bd9 in soo_read (fp=0x0, uio=0xe4b6cc88, active_cred=0xc2884a80,
flags=0, td=0xc1fac480)
at /usr/src5/sys/kern/sys_socket.c:91
#28 0xc04ee865 in dofileread (td=0xc1fac480, fp=0xc2e17bb0, fd=10, buf=0x0,
nbyte=4096, offset=Unhandled dwarf expression opcode 0x93
) at file.h:233
#29 0xc04ee72f in read (td=0xc1fac480, uap=0xe4b6cd14) at
/usr/src5/sys/kern/sys_generic.c:107
#30 0xc05f4fe7 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = -1078001617, tf_edi = 10, tf_esi = 300,
tf_ebp = -1077942168, tf_isp = -457781900, tf_ebx = 134822152, tf_edx = 0,
tf_ecx = 10, tf_eax = 3, tf_trapno = 0, tf_err = 2, tf_eip = 672556795, tf_cs =
31, tf_eflags = 658, tf_esp = -1077942212, tf_ss = 47}) at
/usr/src5/sys/i386/i386/trap.c:1009
#31 0xc05e288f in Xint0x80_syscall () at /usr/src5/sys/i386/i386/exception.s:201
#32 0x002f in ?? ()
#33 0x002f in ?? ()
#34 0xbfbf002f in ?? ()
#35 0x000a in ?? ()
#36 0x012c in ?? ()
#37 0xbfbfe868 in ?? ()
#38 0xe4b6cd74 in ?? ()
#39 0x08093908 in ?? ()
#40 0x in ?? ()
#41 0x000a in ?? ()
#42 0x0003 in ?? ()
#43 0x in ?? ()
#44 0x0002 in ?? ()
#45 0x281666fb in ?? ()
#46 0x001f in ?? ()
#47 0x0292 in ?? ()
#48 0xbfbfe83c in ?? ()
#49 0x002f in ?? ()
#50 0x in ?? ()
#51 0x in ?? ()
#52 0x in ?? ()
#53 0x in ?? ()
#54 0x2c75b000 in ?? ()
#55 0xc22de000 in ?? ()
#56 0xc1fac480 in ?? ()
#57 0xe4b6ccac in ?? ()
#58 0xe4b6cc94 in ?? ()
#59 0xc1f26000 in ?? ()
#60 0xc04ded13 in sched_switch (td=0x12c, newtd=0x8093908, flags=Cannot access
memory at address 0xbfbfe878
) at /usr/src5/sys/kern/sched_4bsd.c:881
Previous frame inner to this frame (corrupt stack?)
(kgdb) quit___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD -STABLE servers repeatedly crashing.
Have you tried to disable HTT? It's doesn't give you alot, and in some cases it decreases performance. Yes, there is absolutely no difference. Disabled HTT in the BIOS and in FreeBSD, the box still crashes. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD -STABLE servers repeatedly crashing.
On Fri, 1 Jul 2005, Kris Kennaway wrote: On Tue, Jun 28, 2005 at 11:26:06AM -0400, Matt Juszczak wrote: After CPUID: 1, the machine locks cold and nothing else is printed to the screen. Try two things: 1) adding 'options KDB_STOP_NMI' to your kernel config. I just learned that you also need to set the debug.kdb.stop_cpus_with_nmi=1 sysctl (e.g. in sysctl.conf). I'm experiencing the same crashes as Matt, but on 5.4-RELEASE-p3. The machine is a HP DL380 G3 and it is heavily loaded (postfix mail server running amavisd-new with antivirus and antispam, so it has heavy IO and CPU load). It does not survive more than a couple of hours, while it is rock stable running 4.11. We have four machines like this, three of them are now again running 4.11 and we left the fourth one at 5.4. We have two other DL380 servers working on our outbound mail queue, but they are not SMP and they are rock stable on 5.4. Without KDB_STOP_NMI, the machine was basically stuck after a crash. Now I've finally landed in the kernel debugger and I have a trace from DDB and have also been able to generate a crashdump with "call doadump". If a developer is willing to investigate, I have: - the vmcore file from the crash (its size is 1GB) - the corresponding kernel, compiled with debug symbols - a GIF of the console at the time of the crash with the backtrace at the time of crash - a dmesg from the box (see below) - the kernel config file Please contact me if you want to investigate this further. Just in case, here is a dmesg from the box: Copyright (c) 1992-2005 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 5.4-RELEASE-p3 #0: Tue Jul 5 18:37:15 CEST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src5/sys/DL380 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.06GHz (3049.93-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 1073717248 (1023 MB) avail memory = 1045372928 (996 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard ioapic2 irqs 32-47 on motherboard ioapic3 irqs 48-63 on motherboard npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x920-0x923 on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: on acpi0 pci0: on pcib0 pci0: at device 3.0 (no driver attached) pci0: at device 4.0 (no driver attached) pci0: at device 4.2 (no driver attached) isab0: at device 15.0 on pci0 isa0: on isab0 atapci0: port 0x2000-0x200f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 ohci0: mem 0xf5ef-0xf5ef0fff irq 7 at device 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered pcib1: on acpi0 pci1: on pcib1 ciss0: port 0x3000-0x30ff mem 0xf7cf-0xf7cf3fff,0xf7dc-0xf7df irq 30 at device 3.0 on pci1 pcib2: on acpi0 pci2: on pcib2 bge0: mem 0xf7ef-0xf7ef irq 29 at device 1.0 on pci2 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:0e:7f:20:22:91 bge1: mem 0xf7ee-0xf7ee irq 31 at device 2.0 on pci2 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:0e:7f:20:22:90 pcib3: on acpi0 pci3: on pcib3 pcib4: on acpi0 pci6: on pcib4 pci6: at device 30.0 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A fdc0: port 0x3f2-0x3f5 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 orm0: at iomem 0xee000-0xe,0xcc000-0xcd7ff,0xc8000-0xcbfff,0xc-0xc7fff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec IP Filter: v3.4.35 initialized. Default = pass all, Logging = enabled acd0: CDROM at ata0-master PIO4 SMP: AP CPU #3 Launc
Re: Proposed makewhatis perl script fix
> Well, in Russian BSD newsgroup I see complaints that even > > $ program | more # and press `q' while program is still running > > giving the same error. I don't see that myself. Blaz Zupan, Medinet d.o.o, Linhartova 21, 2000 Maribor, Slovenia E-mail: [EMAIL PROTECTED], Tel: +386-2-320-6320, Fax: +386-2-320-6325 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Proposed makewhatis perl script fix
> Try the following patch (which I dug up off the Web after the previous > go-round on this problem). It seems to work. > > (The indentation is wrong, I know. I had to apply the patch -l because > the HTMLization of the original mail message hosed the whitespace.) Excellent, this seems to be the fix! Could a commiter please review and commit this? Blaz Zupan, Medinet d.o.o, Linhartova 21, 2000 Maribor, Slovenia E-mail: [EMAIL PROTECTED], Tel: +386-2-320-6320, Fax: +386-2-320-6325 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: System clock out of control
> That fixed it. Thanks, Blaz! > > So now I have to wonder why this fixed the problem? Is this a sign of > some other problem, or is it just something that is an issue with > non-Intel i386 hardware? I believe the apm code switches the whole system to use some other clock source. In my case, it was an old AMD K5 box, on which the clock was running *extermely slow* (like one second every minute). It was originally running Linux and it exhibited the same problem under Linux. We thought it was purely broken hardware or a broken BIOS, I tried upgrading to the latest BIOS - still no go. Later I tried to install FreeBSD on it nevertheless and it worked - but as soon as I installed a custom kernel it failed. Well, now with "device apm" the machine is happily humming along and you wouldn't be reading this message if it wasn't working (the box is now our company firewall, running FreeBSD 4.1.1). Back to your question, somebody more familiar with the apm code might give you the answer. Or somebody more familiar with the system clocks on FreeBSD, maybe [EMAIL PROTECTED]? I'm not sure if he's reading this list, though. Blaz Zupan, Medinet d.o.o, Linhartova 21, 2000 Maribor, Slovenia E-mail: [EMAIL PROTECTED], Tel: +386-2-320-6320, Fax: +386-2-320-6325 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Why cu i suid && sgid
> I presume cisco can be password protected, but what with dialup modems > connected to the server ? Now, evrytime after 'make world' I have to > remember changing permisions to /dev/[cuaa*,ttyd*] devices or cu. Change /dev/MAKEDEV.local so that it modifies the permissions like you want them to be. BTW, make world does not change the devices in /dev in any way, if you don't run /dev/MAKEDEV. Blaz Zupan, Medinet d.o.o, Linhartova 21, 2000 Maribor, Slovenia E-mail: [EMAIL PROTECTED], Tel: +386-2-320-6320, Fax: +386-2-320-6325 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: HEADS UP: OpenSSL 0.9.5a merge
> I feel obliged to mention that one or two people had complained of weird > problems using apache+modssl where netscape refused to authenticate to a > server running -current (but IE worked fine) - but try as I might I could > never replicate these problems on multiple machines, nor could I analyse a > fault from the information they provided to me. In the end, the number of > people who are successfully using SSL in -current, and the number of other > people who need 0.9.5a, convinced me to do the merge. It is actually quite interesting, I was one of those who complained that apache+modssl was not working with OpenSSL from 4.0-RELEASE. Upgrading to 4.1-RELEASE *fixed* the problems. I looked at the diffs between OpenSSL in 4.0 and 4.1 and they were minimal and absolutely irrelevant to the problems I was experiencing. That's *WEIRD*. Blaz Zupan, Medinet d.o.o, Linhartova 21, 2000 Maribor, Slovenia E-mail: [EMAIL PROTECTED], Tel: +386-2-320-6320, Fax: +386-2-320-6325 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: wl0 lockups and box crashes
On Fri, 29 Oct 1999, Randy Bush wrote: > great. then i have screwed up somehow. i do not think i changed anything > from how it ran in 4.0-current, but i must have. but what? > > symptom is i can use it for a little while and then the system freezes. > so the basic configuration is correct, i.e. i am driving the hardware. I do have to mention that I did not do a great deal of testing, I had the card in the box for about a day and in that time I did not notice anything weird (no messages on the console and no noticeble performance loss). So it could be that if I ran for a longer time, problems would trip up. Blaz Zupan, [EMAIL PROTECTED], http://home.amis.net/blaz/ Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: wl0 lockups and box crashes
On Thu, 28 Oct 1999, Randy Bush wrote: > i suspect wl does not work in -stable. is anybody successful with it? I don't know about stable, but I know it works in 3.3-RELEASE. Blaz Zupan, [EMAIL PROTECTED], http://home.amis.net/blaz/ Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
