Re: em 6.6.6 - watchdog timeout
<[EMAIL PROTECTED]> wrote: Hi, snip When running netstat between servers balder and midgard, server balder get watchdog timeouts and resets the connection for a few seconds. Oct 19 13:12:47 balder kernel: em0: watchdog timeout -- resetting s/netstat/netperf/ ... the future isMobile Goran Lowkrantz <[EMAIL PROTECTED]> System Architect, iaMobile AB Sandviksgatan 81, PO Box 58, S-971 03 Luleå, Sweden Mobile: +46(0)70-587 87 82 http://www.ismobile.com ... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
LOCK_PROFILING in -stable
Hey guys, I have LOCK_PROFILING done for a product based on FreeBSD-6, this means I can relatively easily backport LOCK_PROFILING from FreeBSD-7 to FreeBSD-6. Do we want this? I'd like to do it if people want it. -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/104406: [ufs] Processes get stuck in "ufs" state under persistent CPU load
* Oleg Derevenetz <[EMAIL PROTECTED]> [071019 08:17] wrote: > Hi all, > > Can anyone take a look on PR kern/104406 ? I got repeatable hang situation, > but I can't obtain a kernel dump to get result of all show commands from > here: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > > After my break to debugger using Ctrl+Alt+Esc sequence and entering a > "panic" command kernel does not wrote a kernel dump but seems to hang. Can > anyone describe how to obtain a kernel dump in this situation, or at least > say - which output of show commands need in first place to debug this ? > Output of all suggested commands is huge and I afraid of making mistake > when carrying this output from screen to list of paper and back :-) Oleg, one thing you can do to make this less painful is to run your machine's console over serial port. First get a crossover serial cable, make sure it works from one box to another, it should be easy to run "tip com1" on both boxes to ensure that it works. Then you just need to add console=comconsole to /boot/loader.conf and your box's console should come over serial. Then on the machine watching the console, you can just do this: % script Script started, output file is typescript % tip com1 ...do ddb stuff now... ...stop tip % exit now you should have everything logged into a file called "typescript" should save you a big headache. As far as getting a dump from ddb, try this: ddb> call doadump I'm completely at a loss why this isn't a base ddb command "dump" but whatever... :) -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
em lockups during heavy network I/O on RELENG_7
Hello, I have managed to lock my (amd64, RELENG_7) machine up twice today. In both cases, I was transferring a file to my laptop (in one case over SMB, the other over FTP). Both resulted in a hard lock (no panic). One of the lockups had an "em1: watchdog timeout" message on the console, the other had no abnormal messages on the console. Both transfers were over 100baseTx-FD ethernet over my em card (em1). This is a new occurrence on RELENG_7. The box was stable on 6.2-RELEASE. The hardware is as follows: Asus P5B motherboard (BIOS revison 1405) Intel Core 2 Quad Q6600 Two Intel em cards (em0: internet facing, em1: LAN facing) Further below is my full kernel config, but here are the options I have that GENERIC does not (not necessarily in order, as they were sorted when I was diff'ing with GENERIC): device atapicam device coretemp device if_bridge device pf device pflog device tap ident PFLOG64 machine amd64 makeoptions COPTFLAGS="-O2 -pipe" options ALTQ options ALTQ_CBQ options ALTQ_HFSC options ALTQ_NOPCC options ALTQ_PRIQ options ALTQ_RED options ALTQ_RIO options COMPAT_LINUX32 options HZ=1000 options LIBICONV options LIBMCHAIN options NETSMB options SC_PIXEL_MODE options SMBFS options UDF options VGA_WIDTH90 I plan on removing the HZ, LIBICONV, LIBMCHAIN, SC_PIXEL_MODE, and VGA_WIDTH90 options and seeing if that helps. Do any of the other options look like likely culprits? If the above doesn't help, is there a way to debug hard lockups? I have 15mbit FiOS and have maxed em0 out without causing this. So I'm guessing either I'm not pushing enough packets through em0 to induce this, or the problem is related to em1 sharing an interrupt with a USB controller: interrupt total rate irq1: atkbd0 6 0 irq6: fdc010 0 irq17: uhci1+ 91 0 irq19: uhci3+ 924492 32 irq22: em0 85919 3 irq23: em1 uhci2+ 6627 0 cpu0: timer 56950868 1999 cpu1: timer 56950834 1999 cpu2: timer 56950835 1999 cpu3: timer 56950834 1999 Total 228820516 8035 Anyway, here is the full kernel configuration: makeoptionsCOPTFLAGS="-O2 -pipe" machine amd64 cpu HAMMER ident PFLOG64 options COMPAT_IA32 options COMPAT_LINUX32 ## options SMP# Symmetric MultiProcessor Kernel options STOP_NMI options SCHED_4BSD options PREEMPTION options HZ=1000 options INET# InterNETworking 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 UFS_GJOURNAL# Enable gjournal-based UFS options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NETSMB options SMBFS options LIBICONV options LIBMCHAIN options CD9660 # ISO 9660 Filesystem options UDF options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_LABEL # Provides labelization options GEOM_PART_GPT # GUID Partition Tables. options COMPAT_43TTY# Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 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 AHC_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. options AUDIT # Security event auditing # Bus support. Do not remove isa, even if you h
Re: em 6.6.6 - watchdog timeout
OK, I will look into this as soon as I can. Jack On 10/19/07, Philip Murray <[EMAIL PROTECTED]> wrote: > > On 20/10/2007, at 1:06 AM, Goran Lowkrantz wrote: > > > Hi, > > > > After the update of em to 6.6.6 last, I experience watchdog timeouts > > on a server running 6-STABLE. > > > > "me too" on a Supermicro 5015MT+, although I notice my em0 is also > sharing an interrupt with USB (uhci3)... not sure if that's the culprit. > > > > [EMAIL PROTECTED] ~]$ dmesg > Copyright (c) 1992-2007 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 6.2-STABLE #0: Tue Oct 9 07:45:50 NZDT 2007 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC > ACPI APIC Table: > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(R) CPU X3220 @ 2.40GHz (2394.01-MHz 686- > class CPU) > Origin = "GenuineIntel" Id = 0x6f7 Stepping = 7 > > Features > = > 0xbfebfbff > < > FPU > ,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=0xe3bd > AMD Features=0x2010 > AMD Features2=0x1 > Cores per package: 4 > real memory = 2146304000 (2046 MB) > avail memory = 2095353856 (1998 MB) > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > kbd1 at kbdmux0 > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, > RF5413) > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > cpu0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 1.0 on pci0 > pci1: on pcib1 > pcib2: irq 17 at device 28.0 on pci0 > pci9: on pcib2 > pcib3: at device 0.0 on pci9 > pci10: on pcib3 > pcib4: at device 1.0 on pci10 > pci11: on pcib4 > arcmsr0: > mem 0xe020-0xe0200fff,0xe080-0xe0bf irq 26 at device > 14.0 on pci11 > ARECA RAID ADAPTER0: Driver Version 1.20.00.14 2007-2-05 > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.42 2006-10-13 > pcib5: irq 17 at device 28.4 on pci0 > pci13: on pcib5 > em0: port > 0x4000-0x401f mem 0xe030-0xe031 irq 16 at device 0.0 on pci13 > em0: Ethernet address: 00:30:48:90:48:dc > em0: [FAST] > pcib6: irq 16 at device 28.5 on pci0 > pci14: on pcib6 > em1: port > 0x5000-0x501f mem 0xe040-0xe041 irq 17 at device 0.0 on pci14 > em1: Ethernet address: 00:30:48:90:48:dd > em1: [FAST] > uhci0: port 0x3000-0x301f irq 23 at > device 29.0 on pci0 > uhci0: [GIANT-LOCKED] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0x3020-0x303f irq 19 at > device 29.1 on pci0 > uhci1: [GIANT-LOCKED] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port 0x3040-0x305f irq 18 at > device 29.2 on pci0 > uhci2: [GIANT-LOCKED] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub2: 2 ports with 2 removable, self powered > uhci3: port 0x3060-0x307f irq 16 at > device 29.3 on pci0 > uhci3: [GIANT-LOCKED] > usb3: on uhci3 > usb3: USB revision 1.0 > uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub3: 2 ports with 2 removable, self powered > ehci0: mem > 0xe000-0xe3ff irq 23 at device 29.7 on pci0 > ehci0: [GIANT-LOCKED] > usb4: EHCI version 1.0 > usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 > usb4: on ehci0 > usb4: USB revision 2.0 > uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 > uhub4: 8 ports with 8 removable, self powered > pcib7: at device 30.0 on pci0 > pci15: on pcib7 > pci15: at device 0.0 (no driver attached) > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.1 on pci0 > ata0: on atapci0 > ata1: on atapci0 > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 > on acpi0 > sio0: type 16550A > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on > acpi0 > fdc0: [FAST] > ppc0: port 0x378-0x37f,0x778-0x77f irq 7 > drq 3 on acpi0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/9 bytes threshold > ppbus0: on ppc0 > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > pmtimer0 on isa0 > orm0: at iomem 0xc-0xcafff,0xcb000-0xcbfff, > 0xcc000-0xccfff,0xcd000-0xcdfff on isa0 > atkbdc0: at port 0x60,0x6
Re: em lockups during heavy network I/O on RELENG_7
Sorry, I should have also included dmesg output. The "not properly dismounted" errors are obviously from the last crash :) Here is /var/run/dmesg.boot: Copyright (c) 1992-2007 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 7.0-PRERELEASE #4: Tue Oct 16 16:00:16 EDT 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PFLOG Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz (3400.28-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 4 usable memory = 2139217920 (2040 MB) avail memory = 2064588800 (1968 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: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard netsmb_dev: loaded acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7ff0 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 coretemp0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 cpu2: on acpi0 coretemp2: on cpu2 cpu3: on acpi0 coretemp3: on cpu3 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xfd00-0xfdff,0xc000-0xcfff,0xfc00-0xfcff irq 16 at device 0.0 on pci1 uhci0: port 0xe000-0xe01f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe080-0xe09f irq 17 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xfebff400-0xfebff7ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 4 ports with 4 removable, self powered pcib2: irq 16 at device 28.0 on pci0 pci3: on pcib2 pcib3: irq 16 at device 28.4 on pci0 pci2: on pcib3 atapci0: mem 0xfe8fe000-0xfe8f irq 16 at device 0.0 on pci2 atapci0: AHCI Version 01.00 controller with 2 ports detected ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f at device 0.1 on pci2 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] uhci2: port 0xd800-0xd81f irq 23 at device 29.0 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb3: on uhci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered uhci3: port 0xd880-0xd89f irq 19 at device 29.1 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xdc00-0xdc1f irq 18 at device 29.2 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered ehci1: mem 0xfebff000-0xfebff3ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub6: on usb6 uhub6: 6 ports with 6 removable, self powered pcib4: at device 30.0 on pci0 pci4: on pcib4 em0: port 0xcc00-0xcc3f mem 0xfeae-0xfeaf,0xfeac-0xfead irq 22 at device 1.0 on pci4 em0: Ethernet address: 00:0e:0c:6c:b9:16 em0: [FILTER] em1: port 0xc880-0xc8bf mem 0xfea8-0xfea9,0xfea6-0xfea7 irq 23 at device 2.0 on pci4 em1: Ethernet address: 00:0e:0c:6c:b9:0a em1: [FILTER] isab0: at device 31.0 on pci0 isa0: on isab0 atapci2: port 0xec00-0xec07,0xe880-0xe883,0xe800-0xe807,0xe480-0xe483,0xe400-0xe41f mem 0xfebff800-0xfebf irq 19 at device 31.2 on pci0 atapci2: [ITHREAD] atapci2: AHCI Version 01.10 controller with 4 ports detected ata3: on atapci2 ata3: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: port not implemented ata5: [ITHREAD] ata6: on atapci2 ata6: port not implemented ata6: [ITHREAD] ata7: on atapci2 ata7: [ITHREAD] ata8: on atapci2 ata8: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkb
Re: em lockups during heavy network I/O on RELENG_7
> There's another thread on this issue, although that thread seems to > apply to a specific version (of em(4) code, or of NIC PROM revision -- I > don't know, the dmesg output is somewhat ambiguous). Ah sorry, I did see that thread, but did notice the em version was different, and that it didn't appear to be causing a hard lock of the machine. I suppose it could be related, though. Should I track/post to that thread, instead? Sorry if this is a duplicate issue, but it seemed the symptoms were different. Thanks, Josh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em 6.6.6 - watchdog timeout
On 20/10/2007, at 5:03 PM, Jeremy Chadwick wrote: On Sat, Oct 20, 2007 at 11:21:10AM +1300, Philip Murray wrote: "me too" on a Supermicro 5015MT+, although I notice my em0 is also sharing an interrupt with USB (uhci3)... not sure if that's the culprit. I'm not aware of a 5015MT+ model. Maybe you mean 5015M-MT+ or 5015M-T+? We have two 5015M-T+ boxes, one running RELENG_7 and one running RELENG_6, and neither exhibit this problem. Here's relevant em(4) information from both boxes; I do find the vmstat -i IRQ on the 2nd box a little odd, but operationally it seems fine. box1 (RELENG_6) === em0: port 0x4000-0x401f mem 0xe020-0xe021 irq 16 at device 0.0 on pci13 em1: port 0x5000-0x501f mem 0xe030-0xe031 irq 17 at device 0.0 on pci14 irq16: em0 uhci3 117371806 11 irq17: em1 49605005 4 box2 (RELENG_7) === em0: port 0x4000-0x401f mem 0xe800-0xe801 irq 16 at device 0.0 on pci13 em1: port 0x5000-0x501f mem 0xe820-0xe821 irq 17 at device 0.0 on pci14 irq256: em0 502854 4 irq257: em1 5438 0 On box2, IRQ 16 is also shared with uhci3 and vgapci0, but vmstat doesn't seem to show that. uhci3: port 0x3060-0x307f irq 16 at device 29.3 on pci0 vgapci0: port 0x6000-0x60ff mem 0xe000-0xe7ff,0xe830-0xe830 irq 16 at device 0.0 on pci15 Hi Jeremy You don't seem to be running the 6.6.6 driver, which is when the watchdog timeouts started occurring. Had no problems with 6.2.9. Cheers Phil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em lockups during heavy network I/O on RELENG_7
On Fri, Oct 19, 2007 at 11:24:44PM -0400, Josh Carroll wrote: > Sorry, I should have also included dmesg output. The "not properly > dismounted" errors are obviously from the last crash :) There's another thread on this issue, although that thread seems to apply to a specific version (of em(4) code, or of NIC PROM revision -- I don't know, the dmesg output is somewhat ambiguous). http://lists.freebsd.org/pipermail/freebsd-stable/2007-October/037447.html Jack says he's looking into it. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em 6.6.6 - watchdog timeout
On Sat, Oct 20, 2007 at 11:21:10AM +1300, Philip Murray wrote: > "me too" on a Supermicro 5015MT+, although I notice my em0 is also sharing > an interrupt with USB (uhci3)... not sure if that's the culprit. I'm not aware of a 5015MT+ model. Maybe you mean 5015M-MT+ or 5015M-T+? We have two 5015M-T+ boxes, one running RELENG_7 and one running RELENG_6, and neither exhibit this problem. Here's relevant em(4) information from both boxes; I do find the vmstat -i IRQ on the 2nd box a little odd, but operationally it seems fine. box1 (RELENG_6) === em0: port 0x4000-0x401f mem 0xe020-0xe021 irq 16 at device 0.0 on pci13 em1: port 0x5000-0x501f mem 0xe030-0xe031 irq 17 at device 0.0 on pci14 irq16: em0 uhci3 117371806 11 irq17: em1 49605005 4 box2 (RELENG_7) === em0: port 0x4000-0x401f mem 0xe800-0xe801 irq 16 at device 0.0 on pci13 em1: port 0x5000-0x501f mem 0xe820-0xe821 irq 17 at device 0.0 on pci14 irq256: em0 502854 4 irq257: em1 5438 0 On box2, IRQ 16 is also shared with uhci3 and vgapci0, but vmstat doesn't seem to show that. uhci3: port 0x3060-0x307f irq 16 at device 29.3 on pci0 vgapci0: port 0x6000-0x60ff mem 0xe000-0xe7ff,0xe830-0xe830 irq 16 at device 0.0 on pci15 -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em 6.6.6 - watchdog timeout
On 20/10/2007, at 1:06 AM, Goran Lowkrantz wrote: Hi, After the update of em to 6.6.6 last, I experience watchdog timeouts on a server running 6-STABLE. "me too" on a Supermicro 5015MT+, although I notice my em0 is also sharing an interrupt with USB (uhci3)... not sure if that's the culprit. [EMAIL PROTECTED] ~]$ dmesg Copyright (c) 1992-2007 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 6.2-STABLE #0: Tue Oct 9 07:45:50 NZDT 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU X3220 @ 2.40GHz (2394.01-MHz 686- class CPU) Origin = "GenuineIntel" Id = 0x6f7 Stepping = 7 Features = 0xbfebfbff < FPU ,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=0xe3bd AMD Features=0x2010 AMD Features2=0x1 Cores per package: 4 real memory = 2146304000 (2046 MB) avail memory = 2095353856 (1998 MB) ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: irq 17 at device 28.0 on pci0 pci9: on pcib2 pcib3: at device 0.0 on pci9 pci10: on pcib3 pcib4: at device 1.0 on pci10 pci11: on pcib4 arcmsr0: > mem 0xe020-0xe0200fff,0xe080-0xe0bf irq 26 at device 14.0 on pci11 ARECA RAID ADAPTER0: Driver Version 1.20.00.14 2007-2-05 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.42 2006-10-13 pcib5: irq 17 at device 28.4 on pci0 pci13: on pcib5 em0: port 0x4000-0x401f mem 0xe030-0xe031 irq 16 at device 0.0 on pci13 em0: Ethernet address: 00:30:48:90:48:dc em0: [FAST] pcib6: irq 16 at device 28.5 on pci0 pci14: on pcib6 em1: port 0x5000-0x501f mem 0xe040-0xe041 irq 17 at device 0.0 on pci14 em1: Ethernet address: 00:30:48:90:48:dd em1: [FAST] uhci0: port 0x3000-0x301f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x3020-0x303f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x3040-0x305f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x3060-0x307f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xe000-0xe3ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib7: at device 30.0 on pci0 pci15: on pcib7 pci15: at device 0.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pmtimer0 on isa0 orm0: at iomem 0xc-0xcafff,0xcb000-0xcbfff, 0xcc000-0xccfff,0xcd000-0xcdfff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter "TSC" frequency 2394010800 Hz quality 800 Timecounters tick every 1.000 msec Waiting 5 seconds for SCSI devices to settle acd0: CDROM
Re: rpc.statd--256M okay, but 1G?
On Thu, Oct 18, 2007 at 12:07:02PM -0700, Christopher Chen wrote: > Is there a simple and easy reason why rpc.statd would mmap 1G? I've > read the FAQ and understand why it would allocate 256M, but this one > shows 1G--file.c in /usr/src/usr.sbin/rpc.statd is still set to > allocate 256M, btw. > > This is a 6.2 machine on i386, with 4G RAM, but PAE is not enabled. > That's what I would assume, that if PAE was enabled, it may change the > characteristics of that mmap (but even then, the address space of each > process would be the same...) > > The machine is a nfs client, has no exports, and has two mounts. > > Any quick thoughts? > It has been fixed in RELENG_6 in rev. 1.12.8.2 of statd.c: : revision 1.12.8.2 : date: 2007/08/12 01:46:19; author: truckman; state: Exp; lines: +1 -1 : MFC statd.c 1.15 - : The call to init_file() needs to be moved outside the loop in statd.c, : otherwise mmap() gets called multiple times, which eventually fails due : to address space exhaustion on i386. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kern/104406: [ufs] Processes get stuck in "ufs" state under persistent CPU load
Hi all, Can anyone take a look on PR kern/104406 ? I got repeatable hang situation, but I can't obtain a kernel dump to get result of all show commands from here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html After my break to debugger using Ctrl+Alt+Esc sequence and entering a "panic" command kernel does not wrote a kernel dump but seems to hang. Can anyone describe how to obtain a kernel dump in this situation, or at least say - which output of show commands need in first place to debug this ? Output of all suggested commands is huge and I afraid of making mistake when carrying this output from screen to list of paper and back :-) -- Oleg Derevenetz <[EMAIL PROTECTED]> OOD3-RIPE Phone: +7 4732 539880 Fax: +7 4732 531415 http://www.vsi.ru CenterTelecom Voronezh ISPhttp://isp.vsi.ru ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Supermicro X7DBR-8+ hang at boot
On Tuesday 23 January 2007 01:17:57 pm Guy Helmer wrote: > Jack Vogel wrote: > > On 1/23/07, Guy Helmer <[EMAIL PROTECTED]> wrote: > >> Using FreeBSD 6.2, I'm having trouble with the Supermicro X7DBR-8+ > >> motherboard (dual Xeon 5130 CPUs on the Blackford chipset - > >> http://www.supermicro.com/products/motherboard/Xeon1333/5000P/X7DBR-8+.cfm) > >> > >> > >> hanging after printing the "Waiting 5 seconds for SCSI devices to > >> settle" message. The hang doesn't always happen - sometimes we have to > >> go through several reboot cycles for it to happen - but sometimes it > >> happens with every reboot. For those who would suggest that this > >> happens because I'm using Seagate drives, it happens even if we totally > >> remove the SCSI drive (but leave the aic7902 SCSI interfaces enabled) > >> and boot from a SATA disk. Using FreeBSD 6.1, the Intel gigabit > >> ethernet NICs aren't found but the hang doesn't occur. > > ... > > If that isnt it, I would suggest installing using ACPI disabled or > > SAFE if > > needed, and then tweak the kernel after. > hint.apic.0.disabled=1 helped - it hasn't hung yet in several boot > cycles. New dmesg is attached below in case it helps anyone see a > better fix than disabling the APICs. So you got an interrupt storm on IRQ 18 when ahd0 tried to probe and ahd0 got interrupt timeouts. This indicates that ahd0 really lives on IRQ 18, not IRQ 30. Your BIOS is likely busted since ACPI hardcodes these sort of IRQs. You can override the BIOS by doing: set hw.pci5.2.INTA.irq=18 in the loader (or adding a line to loader.conf) and seeing if that fixes the boot with APIC enabled. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: libpcap/tcpdump update
On 2007-10-19 10:48, Max Laier <[EMAIL PROTECTED]> wrote: > Okay. libpcap 0.9.8 and tcpdump 3.9.8 are now imported into HEAD and > RELENG_7. Is anyone eager to pull it down to RELENG_6 as well, > because I don't have the resources available at the moment. The > update was crucial to me in HEAD and RELENG_7 to get a working pflog > tcpdump, but RELENG_6 isn't broken for me ... > > Any takers? If not I might get round to it eventually, but I'd prefer > somebody with genuine interest would step up. Hi Max, I can do this. I may need a bit of help with code-style or parts which I am not very familiar with, but if you think you can do a pre-commit review of the RELENG_6 patches (or alternatively help me find another src-committer who can do this), that would be awesome :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kldxref: file isn't dynamically-linked -- expected behaviour?
On Thu, Oct 18, 2007 at 09:06:55PM +0200, Philipp Ost wrote: > Vlad GALU wrote: >> On 10/18/07, Philipp Ost <[EMAIL PROTECTED]> wrote: >>> Hi list, >>> >>> I'm currently upgrading from 6.2-STABLE (13 Oct. 2007) to RELENG_7. I >>> did the following after csup'ing my sources: >>> # make kernel-toolchain >>> # make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=MYKERNEL >>> # make -DALWAYS_CHECK_MAKE installkernel KERNCONF=MYKERNEL >>> >>> The last thing 'installkernel' reports is: >>> [...] >>> kldxref /boot/kernel >>> kldxref: file isn't dynamically-linked >>> [...] >>> >>> This message is repeated 514 times... ;-) Is this expected behaviour? >>> Before I do a reboot I would like to make sure "everything works" as I >>> rely on that particular machine. >>> >>> If needed I can provide full logs; MYKERNEL is a cut down version of >>> GENERIC with atapicam, drm, radeondrm, sound added ;-) >>> >>> >>> Thanks in advance for any hint/help! >>> >>It's harmless. Once you boot with your new RELENG_7 they will >> disappear on the next kernel build/install. > > Thanks a lot. I saw this message for the first time in my life and was a > little bit concerned about it... But if everything seems to be fine I will > give it a try. > As others have pointed out, these messages are harmless. It's caused by the old (6.x version) kldxref(8) binary trying to hash the *.symbols files that are installed along with debug versions of kernel and module objects, and that contain symbol information needed for debugging, and aren't dynamically linked ELF files. So the old kldxref(8) ignores these files, but issues a warning. Once you upgrade to 7.x, you'll have also installed the new (7.x version) of kldxref(8) that is aware of .symbols files, so warnings will be gone. Technically, kldxref(8) should be a cross-tool (in the buildworld sense), but last time I tried to convert it to be a cross-tool several years ago it wasn't very easy. It's quite possible it will be easier now that we only support limited upgrade paths. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
em 6.6.6 - watchdog timeout
Hi, After the update of em to 6.6.6 last, I experience watchdog timeouts on a server running 6-STABLE. I have two identical servers with Intel D915GAV boards. Both have Intel PRO/1000 PCI-Express network cards. Server balder: em0: port 0xac00-0xac1f mem 0xff60-0xff61,0xff62-0xff63 irq 16 at device 0.0 on pci5 em0: Ethernet address: 00:1b:21:00:48:c4 em0: [FAST] # vmstat -i interrupt total rate irq1: atkbd0 3 0 irq4: sio0 2 0 irq6: fdc012 0 irq14: ata0 68 0 irq16: em0 uhci3 219828879450 irq19: uhci1++ 4287947 8 irq22: ahc0232717293476 irq23: uhci0 ehci0 1 0 cpu0: timer976552804 2000 Total 1433387009 2935 # netstat -i NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll em01500 00:1b:21:00:48:c4 209880531 773 2062284 0 em01500 10.255.253/24 balder215210996 - 212337968 - - plip0 15000 00 0 0 lo0 16384 12040055 0 12055326 0 0 lo0 16384 fe80:3::1 fe80:3::10 -0 - - lo0 16384 localhost ::1 6 -6 - - lo0 16384 your-net localhost 6249979 - 6249980 - - 00:00.0 Host bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL Memory Controller Hub (rev 04) 00:01.0 PCI bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL PCI Express Root Port (rev 04) 00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Integrated Graphics Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 03) 00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 3 (rev 03) 00:1c.3 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 4 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3) 00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03) 00:1f.2 IDE interface: Intel Corporation 82801FB/FW (ICH6/ICH6W) SATA Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03) 05:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06) 06:01.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U (rev 01) Server midgard: em0: port 0xac00-0xac1f mem 0xff50-0xff51,0xff52-0xff53 irq 16 at device 0.0 on pci5 em0: Ethernet address: 00:15:17:0e:05:f7 [EMAIL PROTECTED]> vmstat -i interrupt total rate irq1: atkbd0 11 0 irq4: sio0 2142746 0 irq6: fdc014 0 irq14: ata0 252 0 irq16: em0+40101164 irq19: atapci1+ 7932757 1 irq22: ahc0 87074425 21 cpu0: timer 3807810138937 Total 4571600444 1125 [EMAIL PROTECTED]> netstat -i NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll em01500 00:15:17:0e:05:f7 343771280 0 474609731 0 0 em01500 10.255.253/24 midgard 347467842 - 478700485 - - plip0 15000 00 0 0 lo0 16384 16821054 0 16947668 0 0 lo0 16384 fe80:3::1 fe80:3::10 -0 - - lo0 16384 localhost ::1 2610 - 2610 - - lo0 16384 your-net localhost 12616879 - 12616879 - - lo0 16384 10.255.253.12 appsrv1 0 -0 - - lo0 16384 10.255.253.10 ca.glz.hidden-pow0 -0 - - lo0 16384 10.255.253.11 test 0 -
Re: Mounting smbfs as user?
on 18/10/2007 17:29 Ivan Voras said the following: > Krassimir Slavchev wrote: >> Hi, >> >> Ivan Voras wrote: > > >>> The same command works under root, and the appropriate klds are loaded: >> Only superuser can load modules. If you try to load module by regular >> user you will get: kldload: can't load .ko: Operation not permitted > > > To clarify: the modules were loaded before I tried either as user or as > root. > This doesn't seem to be entirely smbfs-specific, but rather specific to internal workings of iconv modules. Here's some information from a while ago: http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031501.html I didn't get any useful information since then and still have to use a workaround of doing any mount as root to get iconv initialized first and then all subsequent user mounts are successful. While on one hand this seems like only a minor annoyance, on the other hand it indicates a problem in iconv internal workings and this should be considered a bug as this breaks a user-mount feature. Probably a PR is due here, I was just too lazy to open it when I first hit the problem. -- Andriy Gapon ___ 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 , km_stack = {ss_sp = 0x7f9ff000
,
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:
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: kldxref: file isn't dynamically-linked -- expected behaviour?
On 19 Oct 2007, at 8:04, Chris Chou wrote: I saw the same message when upgrading from RELENG_6 to RELENG_7, and it disappeared when I re-installed the RELENG_7 kernel. Was your user land already upgraded to RELENG_7 ? if concerned, find the version 7 kldxref from /usr/obj and rerun it. apart from that and a few other nits that aren't really worth mentioning as I reused my kernel config from six the upgrade was really smooth. Thanks to all who participated in getting RELENG_7 branched! - Ruben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kldxref: file isn't dynamically-linked -- expected behaviour?
Ruslan Ermilov wrote: On Thu, Oct 18, 2007 at 09:06:55PM +0200, Philipp Ost wrote: Vlad GALU wrote: On 10/18/07, Philipp Ost <[EMAIL PROTECTED]> wrote: Hi list, I'm currently upgrading from 6.2-STABLE (13 Oct. 2007) to RELENG_7. I did the following after csup'ing my sources: # make kernel-toolchain # make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=MYKERNEL # make -DALWAYS_CHECK_MAKE installkernel KERNCONF=MYKERNEL The last thing 'installkernel' reports is: [...] kldxref /boot/kernel kldxref: file isn't dynamically-linked [...] This message is repeated 514 times... ;-) Is this expected behaviour? Before I do a reboot I would like to make sure "everything works" as I rely on that particular machine. If needed I can provide full logs; MYKERNEL is a cut down version of GENERIC with atapicam, drm, radeondrm, sound added ;-) Thanks in advance for any hint/help! It's harmless. Once you boot with your new RELENG_7 they will disappear on the next kernel build/install. Thanks a lot. I saw this message for the first time in my life and was a little bit concerned about it... But if everything seems to be fine I will give it a try. As others have pointed out, these messages are harmless. It's caused by the old (6.x version) kldxref(8) binary trying to hash the *.symbols files that are installed along with debug versions of kernel and module objects, and that contain symbol information needed for debugging, and aren't dynamically linked ELF files. So the old kldxref(8) ignores these files, but issues a warning. Once you upgrade to 7.x, you'll have also installed the new (7.x version) of kldxref(8) that is aware of .symbols files, so warnings will be gone. Technically, kldxref(8) should be a cross-tool (in the buildworld sense), but last time I tried to convert it to be a cross-tool several years ago it wasn't very easy. It's quite possible it will be easier now that we only support limited upgrade paths. Thanks for the explanation of the technical background. In the meantime I did the upgrade to 7.0 and also rebuilt the kernel -- as pointed out the warnings are gone ;-) Seems like I was a little bit too concernced about some (possible) breakage... Thanks again for all the answers! Cheers, Philipp -- http://www.familie-ost.info/~pj ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ULE vs. 4BSD in RELENG_7
Josh Carroll wrote: I have noticed some performance discrepancies with ULE and 4BSD in RELENG_7, specifically with ffmpeg. I have all the kernel debugging options disabled, and as I understand it, the userland debugging is all off by default in RELENG_7. Here are a couple of additional benchmarks comparing the schedulers on my system: make -j8 -DNOCLEAN buildkernel 4BSD: 3:25.56 ULE: 3:39.20 Difference: -6.6 % ubench (CPU): 4BSD: 1705258 ULE: 1713510 Difference: +0.48 % super-smack (select-key 10 1): 4BSD: 55044.38 ULE: 68085.21 Difference: +23.69 % super-smack (update-select 10 1): 4BSD: 16734.15 ULE: 17631.43 Difference: +5.36 % So at least for the MySQL super-smack benchmark (I know it's a rather contrived benchmark), ULE is significantly faster for select-key and a decent improvement for update-select. ubench is about the same, but building a kernel is also slower with ULE. Here are some buildworld measures (extract from a buildaton): i386: 6.2-RELEASE -j4:746.08 real 1996.38 user 468.91 sys1535.1 RSA -j6:595.31 real 1957.31 user 539.24 sys2304.9 RSA -j8:534.21 real 1957.76 user 567.06 sys3068.5 RSA M1000: 492.64 real 1956.58 user 587.41 sys 100: 526.22 real 1936.98 user 559.49 sys3073.8 RSA M100: 474.26 real 1947.09 user 563.95 sys -j10: 550.18 real 1975.54 user 588.33 sys -j12: 550.23 real 1976.88 user 602.65 sys -j16: 559.22 real 1972.19 user 634.29 sys i386: 7.0-current (as of 10/16/2007) - SCHED_4BSD -j4: 1072.64 real 2880.29 user 561.13 sys1495.7 RSA -j6:842.91 real 2813.75 user 638.91 sys2244.8 RSA -j8:758.48 real 2824.23 user 704.00 sys2990.1 RSA M1000: 696.12 real 2820.53 user 706.97 sys 100: 752.58 real 2809.97 user 685.35 sys2993.2 RSA M100: 666.58 real 2804.72 user 714.01 sys -j10: 763.82 real 2843.44 user 743.77 sys -j12: 785.12 real 2845.11 user 770.31 sys -j16: 805.02 real 2848.06 user 819.53 sys i386: 7.0-current (as of 10/16/2007) - SCHED_ULE -j4: 1047.00 real 2857.59 user 486.93 sys1494.2 RSA -j6:831.10 real 2793.94 user 524.58 sys2242.6 RSA -j8:803.34 real 2796.46 user 552.56 sys2991.0 RSA M1000: 709.77 real 2793.20 user 572.27 sys 100: 785.18 real 2765.14 user 545.57 sys2991.4 RSA M100: 707.09 real 2769.88 user 572.92 sys -j10: 813.36 real 2808.13 user 587.51 sys -j12: 824.23 real 2817.60 user 618.00 sys -j16: 856.11 real 2847.68 user 721.97 sys - Conditions: Machine: Intel SR2520 - S5000PAL, 2xE5345 (8 cores, 2.33Ghz), 8G, 1xsata) Generic kernel; /usr/obj/* removed after each run; Runs done after a reboot; softupdates on all fs; RSA = openssl speed -multi rsa1024; M1000 = noatime /usr, kern.hz=1000, tar cf /dev/null /usr/src before run. M100 = idem with kern.hz=100 100 = generic test with kern.hz=100 (To be compared with -j8 line). (M variants to minimize disk contention reading src; Variants measured only on #-core sweetspot (8 here)). - Remarks: - There seems to be a loss of efficiency on openssl code. Not scheduler related. An indication of compiler change ? - 6.2 results only for information. RSA left aside, there is no direct equivalence between buildworld workload nor duration/level of parallelism between 6.2 and 7.0. Also, Amdhal's law limits efficiency on increasing cores number. - ULE tends to be more efficient than 4BSD when there are available cores (1.0244 and 1.0142 ratio on -j4 and -j6) but less efficient as load increase (0.9807 to 0.9403 from -j8 to -j16). - ULE seems to be less sensitive to Hz than 4BSD (1.0037 from 1.0443 on M1000/M100 variants ratio). (Beware of side effects on time/delay bandwidth estimator at network level). -- RN. IeM ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: libpcap/tcpdump update
Hi Max, On Fri, Oct 19, 2007 at 10:48:52AM +0200, Max Laier wrote: > Okay. libpcap 0.9.8 and tcpdump 3.9.8 are now imported into HEAD and > RELENG_7. Thank you for updating these two components! Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> pgp2pFfzwjHEk.pgp Description: PGP signature
Re: libpcap/tcpdump update
Okay. libpcap 0.9.8 and tcpdump 3.9.8 are now imported into HEAD and RELENG_7. Is anyone eager to pull it down to RELENG_6 as well, because I don't have the resources available at the moment. The update was crucial to me in HEAD and RELENG_7 to get a working pflog tcpdump, but RELENG_6 isn't broken for me ... Any takers? If not I might get round to it eventually, but I'd prefer somebody with genuine interest would step up. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: Reproducable, possibly NFS related, fatal double fault in 6.2-R-p7
Quoting Kris Kennaway <[EMAIL PROTECTED]>: Clifton Royston wrote: On Tue, Oct 16, 2007 at 01:01:46PM -0700, Chris H. wrote: excerpt from this list titled: NFS == lock && reboot, that I posted follows: --8<---SNIP---8<-SNIP-8<--- # uname -a FreeBSD host.domain.tld 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 26 16:27:14 PST 2007 Greetings, Does anyone know when NFS and friends will be working again? I haven't been able to /safely/ use it from 4.8 on. I remember some talk on the list sometime ago and then it seemed to be resolved, as the discussion ended. So I thought it was fixed. Seems not. :( My scenario; mount host off root: mount script exec'd follows... #!/bin/sh - mount -t nfs host.domain.tld:/ /host mount -t nfs host.domain.tld:/var /host/var confirm mount... # ls /host .snapCOPYRIGHTbin ... usrvartmp OK looks good... # cp /path/to/approx/10Mb/file /host/path/to/dest/dir/ Fatal double fault eis 0x0blah eiblah blah0x panic double fault no dump device defined rebooting in 15sec... Hmmm... that's not good. :( --8<---SNIP---8<-SNIP-8<--- My final solution was to change the lines in /etc/rc.conf from: nfs_client_enable="YES" nfs_reserved_port_only="YES" nfs_server_enable="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" rpcbind_enable="YES" to: nfs_client_enable="YES" nfs_reserved_port_only="YES" nfs_server_enable="YES" #rpc_lockd_enable="YES" #rpc_statd_enable="YES" rpcbind_enable="YES" Making those changes ended the "Fatal double fault && reboot in 15 seconds..." Thanks for this very timely mention! The cluster of servers I am about to upgrade from 4.8 to 6.2 relies heavily on NFS to an old Netapp. If I have got to disable rpc_lockd and rpc_statd, it's good to know that now! Can I ask, can anybody confirm that they're running 6.2 on NFS successfully *with* lockd and statd? Er, yes, of course it does. The old message he is quoting is bogus on its own, While I'll grant you that I haven't *yet* found/taken the time to create a dump device and re-enable rpd_lockd && rpc_statd && cp 10Mb file to mount point to produce an *instantaneous* "Fatal double fault". I don't think it's fair to label my original post entirely /bogus/ - especially in light of the recent post I replied to. Which seems to have some very common ground. I should probably mention that since my last posting (my original thread), I have some 20+ RELENG_6_2 boxen that *do* have rpd_lockd + rpc_statd enabled. Yet none of them produce a "Fatal double fault". They are all Tyan SMP boards with dual onboard fxp's - as opposed to the Nvidia UP which has a single onboard nve. They are all inter-connected via NFS. I have a 750Gb drive hanging off the /problematic/ Nvidia board, that I had intended to use for NFS back-up's. But given the NFS issue I had with it, it didn't seem to be the best solution. If anyone felt like throwing me a "cheat sheet" for creating a dump device out of that drive and a "quickie" for producing a backtrace. I'm sure I'd be better able to find the required time to produce the required information. I'm sorry. It's just that I'm a hundred million miles away from that right now. As I've been building several large web applications, and their deadline is fast approaching. FWIW I bounced all the servers today, and therefore have recent /verbose/ dmesg's. Should any of the information they provide, be of any help/use to anyone. Take care. :) --Chris I don't know if he ever was able to provide meaningful traces but it may well be nve as in the upthread discussion. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em lockups during heavy network I/O on RELENG_7
On Sat, Oct 20, 2007 at 12:10:30AM -0400, Josh Carroll wrote: > > There's another thread on this issue, although that thread seems to > > apply to a specific version (of em(4) code, or of NIC PROM revision -- I > > don't know, the dmesg output is somewhat ambiguous). > > Ah sorry, I did see that thread, but did notice the em version was > different, and that it didn't appear to be causing a hard lock of the > machine. I suppose it could be related, though. Should I track/post to > that thread, instead? Sorry if this is a duplicate issue, but it > seemed the symptoms were different. My apologies -- after being educated (the version number shown in the device output is actually the driver version and not a PROM version), your issue here is likely separate. The driver revision shown here is 6.5.3. Jack should be able to help track this down though... (I like how I'm volunteering him for more work, haha. :-) ) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em 6.6.6 - watchdog timeout
<[EMAIL PROTECTED]> wrote: Hi, After the update of em to 6.6.6 last, I experience watchdog timeouts on a server running 6-STABLE. I have two identical servers with Intel D915GAV boards. Both have Intel PRO/1000 PCI-Express network cards. Server balder: em0: port 0xac00-0xac1f mem 0xff60-0xff61,0xff62-0xff63 irq 16 at device 0.0 on pci5 em0: Ethernet address: 00:1b:21:00:48:c4 em0: [FAST] # vmstat -i interrupt total rate irq1: atkbd0 3 0 irq4: sio0 2 0 irq6: fdc012 0 irq14: ata0 68 0 irq16: em0 uhci3 219828879450 irq19: uhci1++ 4287947 8 irq22: ahc0232717293476 irq23: uhci0 ehci0 1 0 cpu0: timer976552804 2000 Total 1433387009 2935 # netstat -i NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll em01500 00:1b:21:00:48:c4 209880531 773 20622 84 0 em01500 10.255.253/24 balder215210996 - 212337968 - - plip0 15000 00 0 0 lo0 16384 12040055 0 12055326 0 0 lo0 16384 fe80:3::1 fe80:3::10 -0 - - lo0 16384 localhost ::1 6 -6 - - lo0 16384 your-net localhost 6249979 - 6249980 - - 00:00.0 Host bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL Memory Controller Hub (rev 04) 00:01.0 PCI bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL PCI Express Root Port (rev 04) 00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Integrated Graphics Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 03) 00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 3 (rev 03) 00:1c.3 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 4 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3) 00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03) 00:1f.2 IDE interface: Intel Corporation 82801FB/FW (ICH6/ICH6W) SATA Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03) 05:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06) 06:01.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U (rev 01) Server midgard: em0: port 0xac00-0xac1f mem 0xff50-0xff51,0xff52-0xff53 irq 16 at device 0.0 on pci5 em0: Ethernet address: 00:15:17:0e:05:f7 [EMAIL PROTECTED]> vmstat -i interrupt total rate irq1: atkbd0 11 0 irq4: sio0 2142746 0 irq6: fdc014 0 irq14: ata0 252 0 irq16: em0+40101164 irq19: atapci1+ 7932757 1 irq22: ahc0 87074425 21 cpu0: timer 3807810138937 Total 4571600444 1125 [EMAIL PROTECTED]> netstat -i NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll em01500 00:15:17:0e:05:f7 343771280 0 474609731 0 0 em01500 10.255.253/24 midgard 347467842 - 478700485 - - plip0 15000 00 0 0 lo0 16384 16821054 0 16947668 0 0 lo0 16384 fe80:3::1 fe80:3::10 -0 - - lo0 16384 localhost ::1 2610 - 2610 - - lo0 16384 your-net localhost 12616879 - 12616879 - - lo0 16384 10.255.253.12 appsrv1 0 -0 - - lo0 16384 10.255.253.10 ca.glz.hidden-pow0 -0 - - lo0 16384 10.255.253.11 test 0 -0 - - lo0 16384 10.255.25
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 "<20>Oct 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 "<20>Oct 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" -- "<20>Oct 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 "<20>Oct 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 "<20>Oct 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: 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]"
