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 have
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: PTLTD APIC 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=0xe3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2010NX,LM AMD Features2=0x1LAHF Cores per package: 4 real memory = 2146304000 (2046 MB) avail memory = 2095353856 (1998 MB) ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: PTLTD RSDT 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: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge irq 17 at device 28.0 on pci0 pci9: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 0.0 on pci9 pci10: ACPI PCI bus on pcib3 pcib4: PCI-PCI bridge at device 1.0 on pci10 pci11: PCI bus on pcib4 arcmsr0: Areca SATA Host Adapter RAID Controller 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: ACPI PCI-PCI bridge irq 17 at device 28.4 on pci0 pci13: ACPI PCI bus on pcib5 em0: Intel(R) PRO/1000 Network Connection Version - 6.6.6 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: ACPI PCI-PCI bridge irq 16 at device 28.5 on pci0 pci14: ACPI PCI bus on pcib6 em1: Intel(R) PRO/1000 Network Connection Version - 6.6.6 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: UHCI (generic) USB controller port 0x3000-0x301f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: UHCI (generic) USB controller 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: UHCI (generic) USB controller port 0x3020-0x303f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: UHCI (generic) USB controller 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: UHCI (generic) USB controller port 0x3040-0x305f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: UHCI (generic) USB controller 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: UHCI (generic) USB controller port 0x3060-0x307f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: UHCI (generic) USB controller 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: Intel 82801GB/R (ICH7) USB 2.0 controller 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: Intel 82801GB/R (ICH7) USB 2.0 controller 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: ACPI PCI-PCI bridge at device 30.0 on pci0 pci15: ACPI PCI bus on pcib7 pci15: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH7 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.1 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1
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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF Cores per package: 4 usable memory = 2139217920 (2040 MB) avail memory = 2064588800 (1968 MB) ACPI APIC Table: MSTEST OEMAPIC 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 Version 2.0 irqs 0-23 on motherboard netsmb_dev: loaded acpi0: MSTEST TESTONLY 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: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 cpu0: ACPI CPU on acpi0 coretemp0: CPU On-Die Thermal Sensors on cpu0 cpu1: ACPI CPU on acpi0 coretemp1: CPU On-Die Thermal Sensors on cpu1 cpu2: ACPI CPU on acpi0 coretemp2: CPU On-Die Thermal Sensors on cpu2 cpu3: ACPI CPU on acpi0 coretemp3: CPU On-Die Thermal Sensors on cpu3 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display mem 0xfd00-0xfdff,0xc000-0xcfff,0xfc00-0xfcff irq 16 at device 0.0 on pci1 uhci0: UHCI (generic) USB controller port 0xe000-0xe01f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: UHCI (generic) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: UHCI (generic) USB controller port 0xe080-0xe09f irq 17 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: UHCI (generic) USB controller on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: EHCI (generic) USB 2.0 controller 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: EHCI (generic) USB 2.0 controller on ehci0 usb2: USB revision 2.0 uhub2: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 on usb2 uhub2: 4 ports with 4 removable, self powered pcib2: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci3: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge irq 16 at device 28.4 on pci0 pci2: ACPI PCI bus on pcib3 atapci0: JMicron JMB363 SATA300 controller mem 0xfe8fe000-0xfe8f irq 16 at device 0.0 on pci2 atapci0: AHCI Version 01.00 controller with 2 ports detected ata0: ATA channel 0 on atapci0 ata0: [ITHREAD] ata1: ATA channel 1 on atapci0 ata1: [ITHREAD] atapci1: JMicron JMB363 UDMA133 controller port 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f at device 0.1 on pci2 atapci1: [ITHREAD] ata2: ATA channel 0 on atapci1 ata2: [ITHREAD] uhci2: UHCI (generic) USB controller port 0xd800-0xd81f irq 23 at device 29.0 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb3: UHCI (generic) USB controller on uhci2 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb3 uhub3: 2 ports with 2 removable, self powered uhci3: UHCI (generic) USB controller port 0xd880-0xd89f irq 19 at device 29.1 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: UHCI (generic) USB controller on uhci3 usb4: USB revision 1.0 uhub4: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: UHCI (generic) USB controller port 0xdc00-0xdc1f irq 18 at device 29.2 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: UHCI (generic) USB controller on uhci4 usb5: USB revision 1.0 uhub5: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb5 uhub5: 2 ports with 2 removable, self powered ehci1: EHCI (generic) USB 2.0 controller mem 0xfebff000-0xfebff3ff irq 23 at device 29.7 on pci0 ehci1:
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: Intel(R) PRO/1000 Network Connection Version - 6.2.9 port 0x4000-0x401f mem 0xe020-0xe021 irq 16 at device 0.0 on pci13 em1: Intel(R) PRO/1000 Network Connection Version - 6.2.9 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: Intel(R) PRO/1000 Network Connection Version - 6.5.3 port 0x4000-0x401f mem 0xe800-0xe801 irq 16 at device 0.0 on pci13 em1: Intel(R) PRO/1000 Network Connection Version - 6.5.3 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: UHCI (generic) USB controller port 0x3060-0x307f irq 16 at device 29.3 on pci0 vgapci0: VGA-compatible display 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: Intel(R) PRO/1000 Network Connection Version - 6.2.9 port 0x4000-0x401f mem 0xe020-0xe021 irq 16 at device 0.0 on pci13 em1: Intel(R) PRO/1000 Network Connection Version - 6.2.9 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: Intel(R) PRO/1000 Network Connection Version - 6.5.3 port 0x4000-0x401f mem 0xe800-0xe801 irq 16 at device 0.0 on pci13 em1: Intel(R) PRO/1000 Network Connection Version - 6.5.3 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: UHCI (generic) USB controller port 0x3060-0x307f irq 16 at device 29.3 on pci0 vgapci0: VGA-compatible display 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: PTLTD APIC 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=0xe3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2010NX,LM AMD Features2=0x1LAHF Cores per package: 4 real memory = 2146304000 (2046 MB) avail memory = 2095353856 (1998 MB) ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: PTLTD RSDT 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: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge irq 17 at device 28.0 on pci0 pci9: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 0.0 on pci9 pci10: ACPI PCI bus on pcib3 pcib4: PCI-PCI bridge at device 1.0 on pci10 pci11: PCI bus on pcib4 arcmsr0: Areca SATA Host Adapter RAID Controller 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: ACPI PCI-PCI bridge irq 17 at device 28.4 on pci0 pci13: ACPI PCI bus on pcib5 em0: Intel(R) PRO/1000 Network Connection Version - 6.6.6 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: ACPI PCI-PCI bridge irq 16 at device 28.5 on pci0 pci14: ACPI PCI bus on pcib6 em1: Intel(R) PRO/1000 Network Connection Version - 6.6.6 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: UHCI (generic) USB controller port 0x3000-0x301f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: UHCI (generic) USB controller 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: UHCI (generic) USB controller port 0x3020-0x303f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: UHCI (generic) USB controller 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: UHCI (generic) USB controller port 0x3040-0x305f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: UHCI (generic) USB controller 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: UHCI (generic) USB controller port 0x3060-0x307f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: UHCI (generic) USB controller 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: Intel 82801GB/R (ICH7) USB 2.0 controller 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: Intel 82801GB/R (ICH7) USB 2.0 controller 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: ACPI PCI-PCI bridge at device 30.0 on pci0 pci15: ACPI PCI bus on pcib7 pci15: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH7 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.1 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 pci0: serial bus, SMBus at device 31.3 (no driver attached) acpi_button0: Power Button on acpi0 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on
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: Intel(R) PRO/1000 Network Connection Version - 6.6.6 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 Link#1 00:1b:21:00:48:c4 209880531 773 2062284 0 em01500 10.255.253/24 balder215210996 - 212337968 - - plip0 1500 Link#2 0 00 0 0 lo0 16384 Link#312040055 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: Intel(R) PRO/1000 Network Connection Version - 6.2.9 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 Link#1 00:15:17:0e:05:f7 343771280 0 474609731 0 0 em01500 10.255.253/24 midgard 347467842 - 478700485 - - plip0 1500 Link#2 0 00 0 0 lo0 16384 Link#316821054 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 - -
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]
Re: connection timed out on freebsd 7.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Yi Wang wrote: Thanks very much. This fixed it for me. Most probably you have an old router which can't handle the more aggressive tcp window scaling algorithm used in RELENG_7. BTW, does this have the similar meaning against 'netsh interface tcp set global autotuning=disabled' in Windows Server 2008?. May be if the effect is the same. On 10/18/07, Vince [EMAIL PROTECTED] wrote: Krassimir Slavchev wrote: Hi, try 'sysctl -w net.inet.tcp.rfc1323=0' Thanks for that, I was having issues connecting to www.freebsd.org from a 7.0-PRERELEASE box and this fixed it for me. Vince Yi Wang wrote: Hi, My box is running FreeBSD 7.0 ( upgrade from 6-stable using src ). My problem is I can't connect to the network outside the router. eg. www.FreeBSD.org. Neither http nor ftp. But I can ping them. I can assure you that DNS works fine and the firewall is turned off. Here's some diagnostic messages: # uname -a FreeBSD wangyi.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #2: Wed Oct 17 19:19:47 CST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYKERNEL i386 # ifconfig -a le0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8VLAN_MTU ether 00:0c:29:3c:47:47 inet 172.20.53.106 netmask 0xff00 broadcast 172.20.53.255 inet 192.168.0.106 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet autoselect status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 vmnet1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:bd:e4:45:00:01 inet 192.168.2.1 netmask 0xff00 broadcast 192.168.2.255 PS: This is the result in vmware. I made a dual boot system and run it in vmware using raw disk. Actually, the real interface is nfe0. Sorry for my poor English. Thanks very much! ___ 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] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHGFTvxJBWvpalMpkRAoQbAJ9allqVR0qStpe5jksOJInyh0y/OACghLvy TYYlQ0elmBR+LcU0lAlUmm0= =+Dtg -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Mimedefang crashes on FreeBSD 6 STABLE, amd64
Hi everybody,
I'm trying to get mimedefang running on amd64. But unfortunatly the threaded
milter part ('mimedefang') does segfault after some time, normally 1-2 minutes.
pid 2331 (mimedefang), uid 1001: exited on signal 11 (core dumped)
gdb /idms/bin/mimedefang mimedefang-2331.core
#0 0x00080066389c in pthread_testcancel () from /lib/libpthread.so.2
[New Thread 0x56 (runnable)]
[New Thread 0x599800 (runnable)]
[New Thread 0x546c00 (runnable)]
[New Thread 0x5ad400 (runnable)]
[New Thread 0x5ad000 (runnable)]
[New Thread 0x599c00 (runnable)]
[New Thread 0x560800 (runnable)]
[New Thread 0x55e800 (runnable)]
[New Thread 0x55ec00 (runnable)]
[New Thread 0x55e400 (runnable)]
[New Thread 0x560c00 (runnable)]
[New Thread 0x58fc00 (runnable)]
[New Thread 0x57fc00 (runnable)]
[New Thread 0x599000 (runnable)]
[New Thread 0x52ac00 (runnable)]
[New Thread 0x57f800 (runnable)]
[New Thread 0x58f000 (runnable)]
[New Thread 0x57f400 (runnable)]
[New Thread 0x58f800 (runnable)]
[New Thread 0x52a800 (runnable)]
[New Thread 0x57f000 (runnable)]
[New Thread 0x546800 (runnable)]
[New Thread 0x52a400 (sleeping)]
[New Thread 0x52a000 (LWP 100058)]
[New Thread 0x524000 (runnable)]
[New LWP 100266]
Unfortunaltly the stack trace doesn't seem to be very usable:
(gdb) where
#0 0x00080066c3fc in kse_thr_interrupt () at kse_thr_interrupt.S:2
#1 0x00080065390a in sig_daemon (arg=0x0) at
/usr/src/lib/libpthread/thread/thr_sig.c:214
#2 0x000800661e2e in kse_sched_single (kmbx=0x521318) at
/usr/src/lib/libpthread/thread/thr_kern.c:886
#3 0x in ?? ()
Cannot access memory at address 0x7fbff000
(gdb) frame 2
#2 0x000800661e2e in kse_sched_single (kmbx=0x521318) at
/usr/src/lib/libpthread/thread/thr_kern.c:886
886 pthread_exit(curthread-start_routine(curthread-arg));
(gdb) p kmbx
$1 = (struct kse_mailbox *) 0x521318
(gdb) p *kmbx
$2 = {km_version = 0, km_curthread = 0x0, km_completed = 0x0, km_sigscaught =
{__bits = {0, 0, 0, 0}}, km_flags = 19,
km_func = 0x800661560 kse_sched_single, km_stack = {ss_sp = 0x7f9ff000
Address 0x7f9ff000 out of bounds,
ss_size = 2097152, ss_flags = 0}, km_udata = 0x51c600, km_timeofday =
{tv_sec = 0, tv_nsec = 0}, km_quantum = 0, km_lwp = 100058,
__spare2__ = {0, 0, 0, 0, 0, 0, 0}}
I've tried to replace libpthread.so.2 with libc_r.6 or libthr.2, but
this doesn't help at all, I get smiliar segfaults. libc_r.6 is a userland
threading library, so it's definitly not the kernel which has a problem.
Are there known bugs with mimedefang on 64bit architectures ?
--
Martin
Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED]
--
ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP: finger -l [EMAIL PROTECTED]
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kldxref: file isn't dynamically-linked -- expected behaviour?
I saw the same message when upgrading from RELENG_6 to RELENG_7, and it disappeared when I re-installed the RELENG_7 kernel. On 10/19/07, Philipp Ost [EMAIL PROTECTED] 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. Regards, Philipp -- 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] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amrd disk performance drop after running under high load
Hi Scott Long wrote: interrupt total rate irq6: fdc0 8 0 irq14: ata0 47 0 irq16: uhci0 1428187319 1851 ^^ [1] irq18: uhci212374352 16 irq23: ehci0 3 0 irq46: amr0 11983237 15 irq64: em01427141755 1850 ^^ [2] cpu0: timer 1540896452 1997 cpu1: timer 1542377798 1999 Total 5962960971 7730 [1] and [2] looks suspicious to me (totals and rate are too close to each other and btw to timers). Let the latter (timers) alone. Do you use any USB device? Can you try to use other network card? That behaviour seems to be an interrupt storm and/or irq collision. It's neither. It's a side effect of a feature that FreeBSD abuses for handling interrupts. Note that amr0 and ehci2 are acting similar. It's mostly harmless, but it does waste CPU cycles. I wouldn't expect this on a recent version of FreeBSD, though, at least not from the e1000 driver. I have this effect on many servers and I believe it is harmless. At once I was trying to reduce CPU usage on the very loaded server and removed USB from kernel. This effect disappeared, but there was no significant difference in CPU usage. I disagree about your words about recent version. I have this effect on many servers with latest FreeBSD-6-stable and em. Actually I have more servers with this effect than without it. With best regards, Alexey Popov ___ 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 N 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 embarrassed cough 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: Intel(R) PRO/1000 Network Connection Version - 6.6.6 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 Link#1 00:1b:21:00:48:c4 209880531 773 20622 84 0 em01500 10.255.253/24 balder215210996 - 212337968 - - plip0 1500 Link#2 0 00 0 0 lo0 16384 Link#312040055 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: Intel(R) PRO/1000 Network Connection Version - 6.2.9 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 Link#1 00:15:17:0e:05:f7 343771280 0 474609731 0 0 em01500 10.255.253/24 midgard 347467842 - 478700485 - - plip0 1500 Link#2 0 00 0 0 lo0 16384 Link#316821054 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
Re: Mimedefang crashes on FreeBSD 6 STABLE, amd64
A kdump output shows always the same output. The file descriptor '108/0x6c' doesn't look very valid -- 36626 mimedefang RET kse_release 0 36626 mimedefang RET kse_release 0 36626 mimedefang RET fork 0 36626 mimedefang CALL kse_release(0x537f70) 36626 mimedefang RET kse_release 0 36626 mimedefang RET kse_release 0 36626 mimedefang CALL kse_release(0x521f70) 36626 mimedefang CALL gettimeofday(0x7f5f8eb0,0) 36626 mimedefang CALL kse_release(0x53ff70) 36626 mimedefang CALL kse_release(0x53bf70) 36626 mimedefang RET kse_release 0 36626 mimedefang RET kse_release 0 36626 mimedefang CALL kse_release(0x521f70) 36626 mimedefang CALL getpid 36626 mimedefang RET getpid 36626/0x8f12 36626 mimedefang CALL sendto(0x3,0x7f5f93b0,0x6c,0,0,0) 36626 mimedefang GIO fd 3 wrote 108 bytes 20Oct 19 11:55:57 mimedefang[36626]: 5422080 - 0x540c00: mimedefang.c(1924): EXIT cleanup: SMFIS_CONTINUE 36626 mimedefang RET sendto 108/0x6c 36626 mimedefang CALL gettimeofday(0x7f5f8f10,0) 36626 mimedefang RET gettimeofday 0 36626 mimedefang CALL getpid 36626 mimedefang RET getpid 36626/0x8f12 36626 mimedefang CALL sendto(0x3,0x7f5f9410,0x6c,0,0,0) 36626 mimedefang GIO fd 3 wrote 108 bytes 20Oct 19 11:55:57 mimedefang[36626]: 5422080 - 0x540c00: mimedefang.c(1888): EXIT mfclose: SMFIS_CONTINUE 36626 mimedefang RET sendto 108/0x6c 36626 mimedefang PSIG SIGSEGV SIG_DFL 36626 mimedefang CALL kse_thr_interrupt(0,0x4,0xb) 36626 mimedefang NAMI /var/core/mimedefang-36626.core -- 20Oct 19 11:53:03 mimedefang[33960]: 5422080 - 0x51de00: mimedefang.c(1922): ENTER cleanup 33960 mimedefang RET sendto 93/0x5d 33960 mimedefang CALL gettimeofday(0x7f5f8eb0,0) 33960 mimedefang RET gettimeofday 0 33960 mimedefang CALL getpid 33960 mimedefang RET getpid 33960/0x84a8 33960 mimedefang CALL sendto(0x3,0x7f5f93b0,0x6c,0,0,0) 33960 mimedefang GIO fd 3 wrote 108 bytes 20Oct 19 11:53:03 mimedefang[33960]: 5422080 - 0x51de00: mimedefang.c(1924): EXIT cleanup: SMFIS_CONTINUE 33960 mimedefang RET sendto 108/0x6c 33960 mimedefang CALL gettimeofday(0x7f5f8f10,0) 33960 mimedefang RET gettimeofday 0 33960 mimedefang CALL getpid 33960 mimedefang RET getpid 33960/0x84a8 33960 mimedefang CALL sendto(0x3,0x7f5f9410,0x6c,0,0,0) 33960 mimedefang GIO fd 3 wrote 108 bytes 20Oct 19 11:53:03 mimedefang[33960]: 5422080 - 0x51de00: mimedefang.c(1888): EXIT mfclose: SMFIS_CONTINUE 33960 mimedefang RET sendto 108/0x6c 33960 mimedefang PSIG SIGSEGV SIG_DFL 33960 mimedefang CALL kse_thr_interrupt(0,0x4,0xb) 33960 mimedefang NAMI /var/core/mimedefang-33960.core -- Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Mimedefang] Re: Mimedefang crashes on FreeBSD 6 STABLE, amd64
Hi, Looks like I found the problem and it was a local patch - ouch. Some casts that worked in i386 didn't work on amd64 ... sigh. Sorry for the noise. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
