From owner-freebsd-scsi@FreeBSD.ORG Mon Feb 9 11:06:58 2009 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9B05106566B for ; Mon, 9 Feb 2009 11:06:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D716D8FC25 for ; Mon, 9 Feb 2009 11:06:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n19B6wOx009252 for ; Mon, 9 Feb 2009 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n19B6wZH009248 for freebsd-scsi@FreeBSD.org; Mon, 9 Feb 2009 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Feb 2009 11:06:58 GMT Message-Id: <200902091106.n19B6wZH009248@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-scsi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 11:06:59 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/131032 scsi [panic] hald causing panic in scsi_sg o kern/130735 scsi [cam] [patch] pass M_NOWAIT to the malloc() call insid o kern/130621 scsi [mpt] tranfer rate is inscrutable slow when use lsi213 o kern/129602 scsi [ahd] ahd(4) gets confused and wedges SCSI bus o kern/128452 scsi [sa] [panic] Accessing SCSI tape drive randomly crashe o kern/128245 scsi [scsi] "inquiry data fails comparison at DV1 step" [re o kern/127927 scsi [isp] isp(4) target driver crashes kernel when set up o kern/126866 scsi [isp] [panic] kernel panic on card initialization o kern/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi o kern/123674 scsi [ahc] ahc driver dumping o kern/123666 scsi [aac] attach fails with Adaptec SAS RAID 3805 controll o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/120487 scsi [sg] scsi_sg incompatible with scanners o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/119668 scsi [cam] [patch] certain errors are too verbose comparing o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load o kern/60598 scsi wire down of scsi devices conflicts with config s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/40895 scsi wierd kernel / device driver bug o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/38828 scsi [dpt] [request] DPT PM2012B/90 doesn't work o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce 33 problems total. From owner-freebsd-scsi@FreeBSD.ORG Tue Feb 10 06:05:02 2009 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6216B106564A for ; Tue, 10 Feb 2009 06:05:02 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id E9E8E8FC16 for ; Tue, 10 Feb 2009 06:05:01 +0000 (UTC) (envelope-from spork@bway.net) Received: (qmail 30429 invoked by uid 0); 10 Feb 2009 06:05:00 -0000 Received: from unknown (HELO toasty.nat.fasttrackmonkey.com) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Feb 2009 06:05:00 -0000 Date: Tue, 10 Feb 2009 01:04:59 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@toasty.nat.fasttrackmonkey.com To: freebsd-scsi@freebsd.org Message-ID: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: 7.1 Panic on degraded disk w/mpt X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 06:05:02 -0000 (posted on -stable already, no takers - added info: full dmesg, crash info from panic when array finished rebuilding, some comments on dmesg) Howdy, I dug around and can't find a PR on this, and the only other report I saw was in this mailing list post that has no replies: http://www.nabble.com/7.1-BETA2-panic-on-mpt-degrade-td20183173.html The hardware is a Dell PowerEdge 860 with the Dell/LSI SAS5 controller: mpt0: port 0xec00-0xecff mem 0xfe9fc000-0xfe9fffff,0xfe9e0000-0xfe9effff irq 16 at device 8.0 on pci2 mpt0: MPI Version=1.5.13.0 The panic is repeatable by forcing the array into a degraded state. When the array finishes rebuilding, the box also panics. Here's my best shot at getting info out of kgdb (panic on array going to degraded state): [root@uniweb /home/spork]# cd /usr/obj/usr/src/sys/BWAY7/ [root@uniweb /usr/obj/usr/src/sys/BWAY7]# kgdb kernel.debug /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x20:0xc044b09b stack pointer = 0x28:0xe6ee5b80 frame pointer = 0x28:0xe6ee5b9c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 17 (swi2: cambio) trap number = 12 panic: page fault cpuid = 0 Uptime: 3m7s Physical memory: 3575 MB Dumping 94 MB: 79 63 47 31 15 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at pcpu.h:196 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) list *0xc044b09b 0xc044b09b is in xpt_done (/usr/src/sys/cam/cam_xpt.c:4832). 4827 if ((done_ccb->ccb_h.func_code & XPT_FC_QUEUED) != 0) { 4828 /* 4829 * Queue up the request for handling by our SWI handler 4830 * any of the "non-immediate" type of ccbs. 4831 */ 4832 sim = done_ccb->ccb_h.path->bus->sim; 4833 switch (done_ccb->ccb_h.path->periph->type) { 4834 case CAM_PERIPH_BIO: 4835 TAILQ_INSERT_TAIL(&sim->sim_doneq, &done_ccb->ccb_h, 4836 sim_links.tqe); (kgdb) backtrace #0 doadump () at pcpu.h:196 #1 0xc061d0f7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc061d3c9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0865fcc in trap_fatal (frame=0xe6ee5b40, eva=20) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc0866230 in trap_pfault (frame=0xe6ee5b40, usermode=0, eva=20) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc0866bc2 in trap (frame=0xe6ee5b40) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc084d45b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc044b09b in xpt_done (done_ccb=0xc6bf5000) at /usr/src/sys/cam/cam_xpt.c:4832 #8 0xc044eee9 in xpt_scan_bus (periph=0xc6984b00, request_ccb=0xc6bf5000) at /usr/src/sys/cam/cam_xpt.c:5395 #9 0xc044d241 in camisr_runqueue (V_queue=Variable "V_queue" is not available. ) at /usr/src/sys/cam/cam_xpt.c:7316 #10 0xc044d39e in camisr (dummy=0x0) at /usr/src/sys/cam/cam_xpt.c:7216 #11 0xc05fb41b in ithread_loop (arg=0xc699d770) at /usr/src/sys/kern/kern_intr.c:1088 #12 0xc05f7f69 in fork_exit (callout=0xc05fb260 , arg=0xc699d770, frame=0xe6ee5d38) at /usr/src/sys/kern/kern_fork.c:810 #13 0xc084d4d0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 And the same info from the next panic which happened when the array finished rebuilding itself: [root@uniweb /usr/obj/usr/src/sys/BWAY7]# kgdb kernel.debug /var/crash/vmcore.1 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x20:0xc044b09b stack pointer = 0x28:0xe6ee5b80 frame pointer = 0x28:0xe6ee5b9c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 17 (swi2: cambio) trap number = 12 panic: page fault cpuid = 0 Uptime: 10h28m7s Physical memory: 3575 MB Dumping 186 MB: 171 155 139 123 107 91 75 59 43 27 11 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at pcpu.h:196 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) (kgdb) list *0xc044b09b 0xc044b09b is in xpt_done (/usr/src/sys/cam/cam_xpt.c:4832). 4827 if ((done_ccb->ccb_h.func_code & XPT_FC_QUEUED) != 0) { 4828 /* 4829 * Queue up the request for handling by our SWI handler 4830 * any of the "non-immediate" type of ccbs. 4831 */ 4832 sim = done_ccb->ccb_h.path->bus->sim; 4833 switch (done_ccb->ccb_h.path->periph->type) { 4834 case CAM_PERIPH_BIO: 4835 TAILQ_INSERT_TAIL(&sim->sim_doneq, &done_ccb->ccb_h, 4836 sim_links.tqe); (kgdb) (kgdb) backtrace #0 doadump () at pcpu.h:196 #1 0xc061d0f7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc061d3c9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0865fcc in trap_fatal (frame=0xe6ee5b40, eva=20) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc0866230 in trap_pfault (frame=0xe6ee5b40, usermode=0, eva=20) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc0866bc2 in trap (frame=0xe6ee5b40) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc084d45b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc044b09b in xpt_done (done_ccb=0xc6bf5000) at /usr/src/sys/cam/cam_xpt.c:4832 #8 0xc044eee9 in xpt_scan_bus (periph=0xc6984b00, request_ccb=0xc6bf5000) at /usr/src/sys/cam/cam_xpt.c:5395 #9 0xc044d241 in camisr_runqueue (V_queue=Variable "V_queue" is not available.) at /usr/src/sys/cam/cam_xpt.c:7316 #10 0xc044d39e in camisr (dummy=0x0) at /usr/src/sys/cam/cam_xpt.c:7216 #11 0xc05fb41b in ithread_loop (arg=0xc699d770) at /usr/src/sys/kern/kern_intr.c:1088 #12 0xc05f7f69 in fork_exit (callout=0xc05fb260 , arg=0xc699d770, frame=0xe6ee5d38) at /usr/src/sys/kern/kern_fork.c:810 #13 0xc084d4d0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 (kgdb) My totally wild-assed guess here is that it's not the controller per-se that's causing this, but the disconnect/connect of the pass device or simply the handling of an "event notification" from the controller, since it looks like "cam_xpt.c" handles a whole mess of stuff. Please let me know how to proceed - I can open a PR if that helps get this worked out. I'll be able to trash this machine for the next week or so before it goes into production. dmesg from a verbose boot follows - there is a good amount of noise from mpt in there. The pass entries look a bit bizarre too. This controller is running the latest firmware Dell has posted. Thanks, Charles ___ Charles Sprickman NetEng/SysAdmin Bway.net - New York's Best Internet - www.bway.net spork@bway.net - 212.655.9344 Copyright (c) 1992-2009 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.1-RELEASE-p2 #2: Sat Jan 31 17:11:10 EST 2009 spork@uniweb.bway.net:/usr/obj/usr/src/sys/BWAY7 Preloaded elf kernel "/boot/kernel/kernel" at 0xc0aad000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0aad1e4. Calibrating clock(s) ... i8254 clock: 1193177 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2800111230 Hz CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2800.11-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf64 Stepping = 4 Features=0xbfebfbff Features2=0xe49d AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 128 entries Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries 1st-level data cache: 16 KB, 8-way set associative, sectored cache, 64 byte line size Trace cache: 12K-uops, 8-way set associative 2nd-level cache: 2-MB, 8-way set associative, 64-byte line size L2 cache: 2048 kbytes, 8-way associative, 64 bytes/line real memory = 3757834240 (3583 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x00000000dc064fff, 3678666752 bytes (898112 pages) avail memory = 3678076928 (3507 MB) Table 'FACP' at 0xfa188 Table 'APIC' at 0xfa27c MADT: Found table at 0xfa27c MP Configuration Table version 1.4 found at 0xc00f0000 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 2 ACPI ID 3: disabled MADT: Found CPU APIC ID 3 ACPI ID 4: disabled ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xbfee pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f0000:e2f4 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 ULE: setup cpu group 0 ULE: setup cpu 0 ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 ULE: setup cpu group 1 ULE: setup cpu 1 ULE: adding cpu 1 to group 1: cpus 1 mask 0x2 ACPI: RSDP @ 0x0xfa030/0x0024 (v 2 DELL ) ACPI: XSDT @ 0x0xfa0a0/0x004C (v 1 DELL PE_SC3 0x00000001 MSFT 0x0100000A) ACPI: FACP @ 0x0xfa188/0x00F4 (v 3 DELL PE_SC3 0x00000001 MSFT 0x0100000A) ACPI: DSDT @ 0x0xdffc0000/0x1C33 (v 1 DELL PE_SC3 0x00000001 MSFT 0x0100000E) ACPI: FACS @ 0x0xdffcfc00/0x0040 ACPI: APIC @ 0x0xfa27c/0x0078 (v 1 DELL PE_SC3 0x00000001 MSFT 0x0100000A) ACPI: SPCR @ 0x0xfa300/0x0050 (v 1 DELL PE_SC3 0x00000001 MSFT 0x0100000A) ACPI: HPET @ 0x0xfa350/0x0038 (v 1 DELL PE_SC3 0x00000001 MSFT 0x0100000A) ACPI: MCFG @ 0x0xfa388/0x003C (v 1 DELL PE_SC3 0x00000001 MSFT 0x0100000A) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled io: null: random: nfslock: pseudo-device hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (Jan 31 2009 17:09:23) npx0: INT 16 interface acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xda85a000 pa 0x1000 pci_open(1): mode 1 addr port (0x0cf8) is 0x80000090 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=27788086) pcibios: BIOS version 2.10 AcpiOsDerivePciId: \\_SB_.PCI0.ISA_.P40C -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.ISA_.P41C -> bus 0 dev 31 func 0 ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 9 10 11 12 Validation 0 5 N 0 3 4 5 6 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 5 6 7 9 10 11 12 Validation 0 3 N 0 3 4 5 6 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 9 10 11 12 Validation 0 10 N 0 3 4 5 6 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 6 N 0 3 4 5 6 7 9 10 11 12 Validation 0 6 N 0 3 4 5 6 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 12 Validation 0 255 N 0 3 4 5 6 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 2 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x2778, revid=0x00 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2779, revid=0x00 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x27d0, revid=0x01 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x27e0, revid=0x01 domain=0, bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x27e2, revid=0x01 domain=0, bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) intpin=c, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x27c8, revid=0x01 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type I/O Port, range 32, base 0xace0, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 20 found-> vendor=0x8086, dev=0x27c9, revid=0x01 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0xacc0, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x27ca, revid=0x01 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=6 map[20]: type I/O Port, range 32, base 0xaca0, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 22 found-> vendor=0x8086, dev=0x27cc, revid=0x01 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfeb00000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 20 found-> vendor=0x8086, dev=0x244e, revid=0xe1 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0b (2750 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27b8, revid=0x01 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27df, revid=0x01 domain=0, bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0288, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type I/O Port, range 32, base 0xfc00, size 4, enabled found-> vendor=0x8086, dev=0x27da, revid=0x01 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 map[20]: type I/O Port, range 32, base 0x8c0, size 5, enabled pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 2 pcib1: I/O decode 0xe000-0xefff pcib1: memory decode 0xfe700000-0xfeafffff pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x8086, dev=0x032c, revid=0x09 domain=0, bus=1, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit found-> vendor=0x8086, dev=0x0326, revid=0x09 domain=0, bus=1, slot=0, func=1 class=08-00-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfe7ff000, size 12, enabled pcib1: requested memory range 0xfe7ff000-0xfe7fffff: good pcib2: at device 0.0 on pci1 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xe000-0xefff pcib2: memory decode 0xfe900000-0xfeafffff pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x1000, dev=0x0054, revid=0x01 domain=0, bus=2, slot=8, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x48 (2160 ns), mingnt=0x40 (16000 ns), maxlat=0x0a (2500 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 1 message in map 0x14 map[10]: type I/O Port, range 32, base 0xec00, size 8, enabled pcib2: requested I/O range 0xec00-0xecff: in range pcib1: requested I/O range 0xec00-0xecff: in range map[14]: type Memory, range 64, base 0xfe9fc000, size 14, enabled pcib2: requested memory range 0xfe9fc000-0xfe9fffff: good pcib1: requested memory range 0xfe9fc000-0xfe9fffff: good map[1c]: type Memory, range 64, base 0xfe9e0000, size 16, enabled pcib2: requested memory range 0xfe9e0000-0xfe9effff: good pcib1: requested memory range 0xfe9e0000-0xfe9effff: good pcib1: matched entry for 1.0.INTA pcib1: slot 0 INTA hardwired to IRQ 16 pcib2: slot 8 INTA is routed to irq 16 mpt0: port 0xec00-0xecff mem 0xfe9fc000-0xfe9fffff,0xfe9e0000-0xfe9effff irq 16 at device 8.0 on pci2 mpt0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xec00 mpt0: Reserved 0x4000 bytes for rid 0x14 type 3 at 0xfe9fc000 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 49 mpt0: [MPSAFE] mpt0: [ITHREAD] mpt0: MPI Version=1.5.13.0 mpt0: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x12 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x12 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0xb (ACK not required). mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt0: 1 Active Volume (2 Max) mpt0: 2 Hidden Drive Members (10 Max) mpt0: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required). mpt0: Enabling SATA WC on phy 0 mpt0: Enabling SATA WC on phy 1 pcib3: at device 28.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xf000-0xfff pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 pcib4: at device 28.4 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0xd000-0xdfff pcib4: memory decode 0xfe500000-0xfe6fffff pcib4: no prefetched decode pci4: on pcib4 pci4: domain=0, physical bus=4 found-> vendor=0x14e4, dev=0x1659, revid=0x11 domain=0, bus=4, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 8 messages, 64 bit map[10]: type Memory, range 64, base 0xfe5f0000, size 16, enabled pcib4: requested memory range 0xfe5f0000-0xfe5fffff: good pcib4: matched entry for 4.0.INTA pcib4: slot 0 INTA hardwired to IRQ 16 bge0: mem 0xfe5f0000-0xfe5fffff irq 16 at device 0.0 on pci4 bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfe5f0000 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x000818, model 0x0018, rev. 0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: bpf attached bge0: Ethernet address: 00:18:8b:f7:5e:f1 bge0: [MPSAFE] bge0: [ITHREAD] pcib5: at device 28.5 on pci0 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0xc000-0xcfff pcib5: memory decode 0xfe300000-0xfe4fffff pcib5: no prefetched decode pci5: on pcib5 pci5: domain=0, physical bus=5 found-> vendor=0x14e4, dev=0x1659, revid=0x11 domain=0, bus=5, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 MSI supports 8 messages, 64 bit map[10]: type Memory, range 64, base 0xfe3f0000, size 16, enabled pcib5: requested memory range 0xfe3f0000-0xfe3fffff: good pcib5: matched entry for 5.0.INTA pcib5: slot 0 INTA hardwired to IRQ 17 bge1: mem 0xfe3f0000-0xfe3fffff irq 17 at device 0.0 on pci5 bge1: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfe3f0000 miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: OUI 0x000818, model 0x0018, rev. 0 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge1: bpf attached bge1: Ethernet address: 00:18:8b:f7:5e:f2 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 50 bge1: [MPSAFE] bge1: [ITHREAD] uhci0: port 0xace0-0xacff irq 20 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xace0 ioapic0: routing intpin 20 (PCI IRQ 20) to vector 51 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 0xacc0-0xacdf irq 21 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xacc0 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 52 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xaca0-0xacbf irq 22 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xaca0 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 53 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfeb00000-0xfeb003ff irq 20 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfeb00000 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: wrong number of companions (7 != 3) usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered uhub4: on uhub3 uhub4: multiple transaction translators uhub4: 4 ports with 4 removable, self powered pcib6: at device 30.0 on pci0 pcib6: domain 0 pcib6: secondary bus 6 pcib6: subordinate bus 6 pcib6: I/O decode 0xb000-0xbfff pcib6: memory decode 0xfe100000-0xfe2fffff pcib6: prefetched decode 0xe8000000-0xefffffff pcib6: Subtractively decoded bridge. pci6: on pcib6 pci6: domain=0, physical bus=6 found-> vendor=0x1002, dev=0x515e, revid=0x02 domain=0, bus=6, slot=5, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x01a7, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xe8000000, size 27, enabled pcib6: requested memory range 0xe8000000-0xefffffff: good map[14]: type I/O Port, range 32, base 0xbc00, size 8, enabled pcib6: requested I/O range 0xbc00-0xbcff: in range map[18]: type Memory, range 32, base 0xfe1f0000, size 16, enabled pcib6: requested memory range 0xfe1f0000-0xfe1fffff: good pcib6: matched entry for 6.5.INTA pcib6: slot 5 INTA hardwired to IRQ 19 vgapci0: port 0xbc00-0xbcff mem 0xe8000000-0xefffffff,0xfe1f0000-0xfe1fffff irq 19 at device 5.0 on pci6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfc00 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0xd0 err=0xd0 lsb=0xd0 msb=0xd0 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x4 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 54 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 55 ata1: [MPSAFE] ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 56 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sio0: irq maps: 0x4c69 0x4c79 0x4c69 0x4c69 sio0: irq maps: 0x4c69 0x4c79 0x4c69 0x4c69 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ioapic0: routing intpin 4 (ISA IRQ 4) to vector 57 sio0: [FILTER] cpu0: on acpi0 cpu0: switching to generic Cx mode est0: enabling SpeedStep est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr e2500000e25 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr e2500000e25 device_attach: est1 attach returned 6 p4tcc1: on cpu1 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it sio: sio0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc8fff,0xec000-0xeffff pnpid ORM0000 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x4c69 0x4c69 0x4c69 0x4c69 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 230923 -> 100000 procfs registered lapic: Divisor 2, Frequency 100003975 hz Timecounter "TSC" frequency 2800111230 Hz quality -100 Timecounters tick every 1.000 msec pflog0: bpf attached lo0: bpf attached hptrr: no controller detected. ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting PIO4 on ICH7 chip acd0: setting UDMA33 on ICH7 chip mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares High-Priority-ReSync ) mpt0:vol0(mpt0:0:0): Using Spare Pool: 0 mpt0:vol0(mpt0:0:0): 2 Members: (mpt0:1:32:0): Primary Online (mpt0:1:1:0): Secondary Online mpt0:vol0(mpt0:0:0): RAID-1 - Optimal mpt0:vol0(mpt0:0:0): Status ( Enabled ) (mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:0:0) (mpt0:vol0:1): Online (mpt0:vol0:0): Physical (mpt0:0:32:0), Pass-thru (mpt0:1:1:0) (mpt0:vol0:0): Online acd0: CDROM drive at ata0 as master acd0: read 4134KB/s (4134KB/s), 256KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, packet acd0: Writes: acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc (probe65:mpt0:1:2:0): error 22 (probe65:mpt0:1:2:0): Unretryable Error (probe65:mpt0:1:2:0): error 22 (probe65:mpt0:1:2:0): Unretryable Error (probe66:mpt0:1:3:0): error 22 (probe66:mpt0:1:3:0): Unretryable Error (probe66:mpt0:1:3:0): error 22 (probe66:mpt0:1:3:0): Unretryable Error (probe67:mpt0:1:4:0): error 22 (probe67:mpt0:1:4:0): Unretryable Error (probe67:mpt0:1:4:0): error 22 (probe67:mpt0:1:4:0): Unretryable Error (probe64:mpt0:1:1:0): CAM Status 0x19 (probe64:mpt0:1:1:0): Retrying Command (probe68:mpt0:1:5:0): error 22 (probe68:mpt0:1:5:0): Unretryable Error (probe68:mpt0:1:5:0): error 22 (probe68:mpt0:1:5:0): Unretryable Error (probe64:mpt0:1:1:0): CAM Status 0x19 (probe64:mpt0:1:1:0): Retrying Command (probe69:mpt0:1:6:0): error 22 (probe69:mpt0:1:6:0): Unretryable Error (probe69:mpt0:1:6:0): error 22 (probe69:mpt0:1:6:0): Unretryable Error (probe64:mpt0:1:1:0): CAM Status 0x19 (probe64:mpt0:1:1:0): Retrying Command (probe0:mpt0:0:0:0): tagged openings now 128 (probe64:mpt0:1:1:0): CAM Status 0x19 (probe64:mpt0:1:1:0): Retrying Command (probe0:mpt0:0:0:1): error 22 (probe0:mpt0:0:0:1): Unretryable Error (probe64:mpt0:1:1:0): error 5 (probe64:mpt0:1:1:0): Retries Exhausted (probe0:mpt0:0:0:2): error 22 (probe0:mpt0:0:0:2): Unretryable Error (probe64:mpt0:1:1:0): CAM Status 0x19 (probe64:mpt0:1:1:0): Retrying Command (probe0:mpt0:0:0:3): error 22 (probe0:mpt0:0:0:3): Unretryable Error (probe64:mpt0:1:1:0): CAM Status 0x19 (probe64:mpt0:1:1:0): Retrying Command (probe0:mpt0:0:0:4): error 22 (probe0:mpt0:0:0:4): Unretryable Error (probe64:mpt0:1:1:0): CAM Status 0x19 (probe64:mpt0:1:1:0): Retrying Command (probe0:mpt0:0:0:5): error 22 (probe0:mpt0:0:0:5): Unretryable Error (probe64:mpt0:1:1:0): CAM Status 0x19 (probe64:mpt0:1:1:0): Retrying Command (probe0:mpt0:0:0:6): error 22 (probe0:mpt0:0:0:6): Unretryable Error (probe64:mpt0:1:1:0): error 5 (probe64:mpt0:1:1:0): Retries Exhausted (probe0:mpt0:0:0:7): error 22 (probe0:mpt0:0:0:7): Unretryable Error (probe70:mpt0:1:7:0): error 22 (probe70:mpt0:1:7:0): Unretryable Error (probe70:mpt0:1:7:0): error 22 (probe70:mpt0:1:7:0): Unretryable Error (probe71:mpt0:1:8:0): error 22 (probe71:mpt0:1:8:0): Unretryable Error (probe71:mpt0:1:8:0): error 22 (probe71:mpt0:1:8:0): Unretryable Error (probe72:mpt0:1:9:0): error 22 (probe72:mpt0:1:9:0): Unretryable Error (probe72:mpt0:1:9:0): error 22 (probe72:mpt0:1:9:0): Unretryable Error da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 300.000MB/s transfers da0: 715255MB (1464842240 512 byte sectors: 255H 63S/T 91182C) GEOM: new disk da0 pass0 at mpt0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-5 device pass0: 300.000MB/s transfers pass1 at mpt0 bus 1 target 0 lun 0 pass1: Fixed unknown SCSI-5 device pass1: Serial Number 5QD56ZXC pass1: 300.000MB/s transfers pass1: Command Queueing Enabled ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 14 to local APIC 1 ioapic0: Assigning ISA IRQ 15 to local APIC 0 ioapic0: Assigning PCI IRQ 16 to local APIC 1 ioapic0: Assigning PCI IRQ 17 to local APIC 0 ioapic0: Assigning PCI IRQ 20 to local APIC 1 ioapic0: Assigning PCI IRQ 21 to local APIC 0 ioapic0: Assigning PCI IRQ 22 to local APIC 1 Trying to mount root from ufs:/dev/da0s1a start_init: trying /sbin/init b bge0: link stagte changed to UP e0: link UP From owner-freebsd-scsi@FreeBSD.ORG Tue Feb 10 06:19:27 2009 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09011106566B for ; Tue, 10 Feb 2009 06:19:27 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id B16428FC0A for ; Tue, 10 Feb 2009 06:19:26 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n1A6JK9L051052; Mon, 9 Feb 2009 23:19:20 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <49911C68.6030203@samsco.org> Date: Mon, 09 Feb 2009 23:19:20 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Charles Sprickman References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org Subject: Re: 7.1 Panic on degraded disk w/mpt X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 06:19:27 -0000 Charles Sprickman wrote: > (posted on -stable already, no takers - added info: full dmesg, crash > info from panic when array finished rebuilding, some comments on dmesg) > > Howdy, > > I dug around and can't find a PR on this, and the only other report I > saw was in this mailing list post that has no replies: > > http://www.nabble.com/7.1-BETA2-panic-on-mpt-degrade-td20183173.html > > The hardware is a Dell PowerEdge 860 with the Dell/LSI SAS5 controller: > > mpt0: port 0xec00-0xecff mem > 0xfe9fc000-0xfe9fffff,0xfe9e0000-0xfe9effff irq 16 at device 8.0 on pci2 > mpt0: MPI Version=1.5.13.0 > > The panic is repeatable by forcing the array into a degraded state. > When the array finishes rebuilding, the box also panics. > > Here's my best shot at getting info out of kgdb (panic on array going to > degraded state): I wonder if the MPT card is temporarily detaching and then reattaching the logical drive when the rebuild completes. The info you posted is inconclusive here. CAM (the FreeBSD SCSI layer) has had some problems handling device detaches, but we've been very fortunate to have someone examining and fixing this recently. Would it be possible for you to upgrade to the most recent 8-CURRENT tree, and re-run your test? If not, I'll see about generating a patchset against 7.1. Scott From owner-freebsd-scsi@FreeBSD.ORG Tue Feb 10 06:49:11 2009 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B6AC106564A for ; Tue, 10 Feb 2009 06:49:11 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id C78808FC0C for ; Tue, 10 Feb 2009 06:49:10 +0000 (UTC) (envelope-from spork@bway.net) Received: (qmail 62099 invoked by uid 0); 10 Feb 2009 06:49:09 -0000 Received: from unknown (HELO toasty.nat.fasttrackmonkey.com) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Feb 2009 06:49:09 -0000 Date: Tue, 10 Feb 2009 01:49:09 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@toasty.nat.fasttrackmonkey.com To: Scott Long In-Reply-To: <49911C68.6030203@samsco.org> Message-ID: References: <49911C68.6030203@samsco.org> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-scsi@freebsd.org Subject: Re: 7.1 Panic on degraded disk w/mpt X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 06:49:11 -0000 On Mon, 9 Feb 2009, Scott Long wrote: > Charles Sprickman wrote: >> (posted on -stable already, no takers - added info: full dmesg, crash info >> from panic when array finished rebuilding, some comments on dmesg) >> >> Howdy, >> >> I dug around and can't find a PR on this, and the only other report I saw >> was in this mailing list post that has no replies: >> >> http://www.nabble.com/7.1-BETA2-panic-on-mpt-degrade-td20183173.html >> >> The hardware is a Dell PowerEdge 860 with the Dell/LSI SAS5 controller: >> >> mpt0: port 0xec00-0xecff mem >> 0xfe9fc000-0xfe9fffff,0xfe9e0000-0xfe9effff irq 16 at device 8.0 on pci2 >> mpt0: MPI Version=1.5.13.0 >> >> The panic is repeatable by forcing the array into a degraded state. When >> the array finishes rebuilding, the box also panics. >> >> Here's my best shot at getting info out of kgdb (panic on array going to >> degraded state): > > I wonder if the MPT card is temporarily detaching and then reattaching > the logical drive when the rebuild completes. IIRC, just before the panic there is a bunch of CAM debug splattered across the monitor. I can run down to the garage and snap a few pics of the monitor after detaching a drive. > The info you posted is inconclusive here. CAM (the FreeBSD SCSI layer) > has had some problems handling device detaches, but we've been very > fortunate to have someone examining and fixing this recently. Yeah, I was looking at the commit log for cam_xpt.c and someone has been very busy... > Would it be possible for you to upgrade to the most recent 8-CURRENT > tree, and re-run your test? If not, I'll see about generating a > patchset against 7.1. Can I get away with just updating the kernel, or is there a simple way to build a live-cd? I don't want to screw with userland, but I'd boot a kernel if that's not too rough - but I suppose my 7.1 kgdb would not know what to do with the dump, right? On the bright side, the controller is not getting so scrambled by the panic that it can no longer write the crashdump. That's a positive! I'm going to go panic it again, I'm getting curious about the messages before the panic... Thanks, Charles > Scott > From owner-freebsd-scsi@FreeBSD.ORG Tue Feb 10 07:14:15 2009 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 615F2106566B for ; Tue, 10 Feb 2009 07:14:15 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 0FF348FC08 for ; Tue, 10 Feb 2009 07:14:14 +0000 (UTC) (envelope-from spork@bway.net) Received: (qmail 80459 invoked by uid 0); 10 Feb 2009 07:14:14 -0000 Received: from unknown (HELO toasty.nat.fasttrackmonkey.com) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Feb 2009 07:14:14 -0000 Date: Tue, 10 Feb 2009 02:14:13 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@toasty.nat.fasttrackmonkey.com To: Scott Long In-Reply-To: Message-ID: References: <49911C68.6030203@samsco.org> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-scsi@freebsd.org Subject: Re: 7.1 Panic on degraded disk w/mpt X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 07:14:15 -0000 On Tue, 10 Feb 2009, Charles Sprickman wrote: > On Mon, 9 Feb 2009, Scott Long wrote: > >> Charles Sprickman wrote: >>> (posted on -stable already, no takers - added info: full dmesg, crash info >>> from panic when array finished rebuilding, some comments on dmesg) >>> >>> Howdy, >>> >>> I dug around and can't find a PR on this, and the only other report I saw >>> was in this mailing list post that has no replies: >>> >>> http://www.nabble.com/7.1-BETA2-panic-on-mpt-degrade-td20183173.html >>> >>> The hardware is a Dell PowerEdge 860 with the Dell/LSI SAS5 controller: >>> >>> mpt0: port 0xec00-0xecff mem >>> 0xfe9fc000-0xfe9fffff,0xfe9e0000-0xfe9effff irq 16 at device 8.0 on pci2 >>> mpt0: MPI Version=1.5.13.0 >>> >>> The panic is repeatable by forcing the array into a degraded state. When >>> the array finishes rebuilding, the box also panics. >>> >>> Here's my best shot at getting info out of kgdb (panic on array going to >>> degraded state): >> >> I wonder if the MPT card is temporarily detaching and then reattaching >> the logical drive when the rebuild completes. > > IIRC, just before the panic there is a bunch of CAM debug splattered across > the monitor. I can run down to the garage and snap a few pics of the monitor > after detaching a drive. OK, some more info here. I wanted to be safe, so I brought the machine down to single user and unmounted everything but /. It did not panic on the drive being removed. So perhaps a quiet filesystem = no panic. Here's what gets spit out on the console: mpt0: mpt_cam_event: 0x16 mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required). mpt0: mpt_cam_event: 0x12 mpt0: Unhandled Event Notify Frame. Event 0x12 (ACK not required). mpt0: mpt_cam_event: 0x16 mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required). (mpt0:vol0:1): Physical Disk Status Changed mpt0: mpt_cam_event: 0x15 mpt0: Unhandled Event Notify Frame. Event 0x15 (ACK not required). mpt0: mpt_cam_event: 0x21 mpt0: Unhandled Event Notify Frame. Event 0x21 (ACK not required). (mpt0:vol0:1): Physical Disk Status Changed mpt0:vol0(mpt0:0:0): Volume Status Changed mpt0: mpt_cam_event: 0x15 mpt0: Unhandled Event Notify Frame. Event 0x15 (ACK not required). mpt0: mpt_cam_event: 0x21 mpt0: Unhandled Event Notify Frame. Event 0x21 (ACK not required). mpt0: mpt_cam_event: 0x15 mpt0: Unhandled Event Notify Frame. Event 0x15 (ACK not required). mpt0: mpt_cam_event: 0x21 mpt0: Unhandled Event Notify Frame. Event 0x21 (ACK not required). mpt0:vol0(mpt0:0:0): RAID-1 - Degraded mpt0:vol0(mpt0:0:0): Status ( Enabled ) (mpt0:vol0:1): No longer configured (probe0:mpt0:1:0:0): error 22 (probe0:mpt0:1:0:0): Unretryable Error (probe2:mpt0:1:2:0): error 22 (probe2:mpt0:1:2:0): Unretryable Error (probe3:mpt0:1:3:0): error 22 (repeats with probe # increasing...) (probe1:mpt0:1:1:0): CAM Status 0x19 (probe1:mpt0:1:1:0): Retrying Command (probe0:mpt0:1:0:0): error 22 (probe0:mpt0:1:0:0): Unretryable Error (pass1:mpt0:1:0:0): lost device (pass1:mpt0:1:0:0): removing device entry So it does appear that at the very least the mpt driver is removing the pass device for that drive, right? And on reattach: mpt0: mpt_cam_event: 0x16 mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required). mpt0: mpt_cam_event: 0x12 mpt0: Unhandled Event Notify Frame. Event 0x12 (ACK not required). mpt0: mpt_cam_event: 0x16 mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required). mpt0: Volume(0:1:0): Physical Disk Status Changed mpt0: mpt_cam_event: 0x15 mpt0: Unhandled Event Notify Frame. Event 0x15 (ACK not required). mpt0: mpt_cam_event: 0x21 mpt0: Unhandled Event Notify Frame. Event 0x21 (ACK not required). (mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:0:0) (mpt0:vol0:1): Online (mpt0:vol0:1): Status ( Out-Of-Sync ) (probe2:mpt0:1:2:0): error 22 (probe2:mpt0:1:2:0): Unretryable Error (probe3:mpt0:1:3:0): error 22 (rinse, repeat) pass1 at mpt0 bus 1 target 0 lun 0 pass1: Fixed unknown SCSI-5 device pass1: Serial Number 5QD56ZXC pass1: 300.000MB/s transfers pass1: Command Queueing Enabled mpt0: mpt_cam_event: 0x15 mpt0: Unhandled Event Notify Frame. Event 0x15 (ACK not required). mpt0: mpt_cam_event: 0x21 mpt0: Unhandled Event Notify Frame. Event 0x21 (ACK not required). mpt0: mpt_cam_event: 0x21 mpt0: Unhandled Event Notify Frame. Event 0x21 (ACK not required). mpt0: mpt_cam_event: 0x21 mpt0: Unhandled Event Notify Frame. Event 0x21 (ACK not required). mpt0:vol0(mpt0:0:0): Volume Status Changed mpt0:vol0(mpt0:0:0): RAID-1 - Degraded mpt0:vol0(mpt0:0:0): Status ( Enabled Re-Syncing ) mpt0:vol0(mpt0:0:0): High Priority Re-Sync mpt0:vol0(mpt0:0:0): 1464842240 of 1464842240 blocks remaining I'm betting it will panic again in a few hours when the rebuild finishes. I'll try the detach again tomorrow with all the filesystems mounted and I'll make sure there's some pending writes when I detach. If I see anything interesting before the panic message on screen, I'll grab it. Thanks, Charles From owner-freebsd-scsi@FreeBSD.ORG Tue Feb 10 18:11:40 2009 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB67B106578E for ; Tue, 10 Feb 2009 18:11:40 +0000 (UTC) (envelope-from sebster@sebster.com) Received: from mail.sebster.com (mail.sebster.com [193.46.80.82]) by mx1.freebsd.org (Postfix) with SMTP id 1CA838FC12 for ; Tue, 10 Feb 2009 18:11:39 +0000 (UTC) (envelope-from sebster@sebster.com) Received: (qmail 77127 invoked from network); 10 Feb 2009 17:44:58 -0000 Received: from unknown (HELO ?10.0.1.6?) (sebster@85.147.225.232) by mail.sebster.com with SMTP; 10 Feb 2009 17:44:58 -0000 Message-ID: <4991BD19.1000409@sebster.com> Date: Tue, 10 Feb 2009 18:44:57 +0100 From: Sebastiaan van Erk User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080309010000010009060007" Subject: Disk performance on ESXi with FreeBSD 7.1 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 18:11:44 -0000 This is a cryptographically signed message in MIME format. --------------ms080309010000010009060007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm running FreeBSD on ESXi but I'm having serious issues with disk performance, and I'm wondering if it might have something to do with the scsi driver (or the virtual hardware not returning proper values for its capabilities or something).. I have both a FreeBSD-amd64 and Linux Ubuntu 8.10-amd64 virtual machine (8GB disk, 512MB RAM, 2-CPU) and run dbench on both of them. The linux machine is out of the box, not optimized for vmware, VMI/paravirtualization is off, as is VMotion. The results for dbench are as follows: 1 2 4 freebsd 12.0009 13.6348 12.9402 (MB/s) linux 376.145 651.314 634.649 (MB/s) Thus there is approx a factor 30 difference for dbench 1, and I cannot imagine linux being that much faster just due to some performance tuning kernel parameters. I tried both the VMware LSI Logic controller and the BusLogic controller. Here is the relevant dmesg output of both: LSI: mpt0: port 0x1080-0x10ff mem 0xf4810000-0xf4810fff irq 17 at device 16.0 on pci0 mpt0: [ITHREAD] mpt0: MPI Version=1.2.0.0 da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 3.300MB/s transfers da0: 8192MB (16777216 512 byte sectors: 255H 63S/T 1044C) BusLogic: bt0: port 0x1060-0x107f mem 0xf4810000-0xf481001f irq 17 at device 16.0 on pci0 bt0: BT-958 FW Rev. 5.07B Ultra Wide SCSI Host Adapter, SCSI ID 7, 192 CCBs bt0: [GIANT-LOCKED] bt0: [ITHREAD] da0 at bt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz DT, offset 15, 16bit) da0: 8192MB (16777216 512 byte sectors: 255H 63S/T 1044C) Something that I noticed was the extremely slow transfer rates mentioned with the da0 device. When I'm running dbench the server is not very busy: CPU: 0.2% user, 0.0% nice, 6.4% system, 0.7% interrupt, 92.7% idle 1172 root 1 -8 0 4604K 1228K biowr 1 0:41 4.98% dbench I really want to get this working because I want to run a big production site on FreeBSD. But currently the disk speed is just unworkable. I was wondering if anybody had any ideas about how to get proper disk speeds on FreeBSD, making it a viable guest operating system. If any other info is needed, I'm willing to invest quite some time to provide it! Regards, Sebastiaan --------------ms080309010000010009060007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUTCC AwMwggJsoAMCAQICEFN8DarMNuuKJDEtfs0UaqUwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDYzMDEzNTE1N1oX DTA5MDYzMDEzNTE1N1owaDEQMA4GA1UEBBMHdmFuIEVyazETMBEGA1UEKhMKU2ViYXN0aWFh bjEbMBkGA1UEAxMSU2ViYXN0aWFhbiB2YW4gRXJrMSIwIAYJKoZIhvcNAQkBFhNzZWJzdGVy QHNlYnN0ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsJDDAeYHVmH/ GVxi+bhFx27dmg++9BdhPJfk8k041sqEqq7oXnR2GT54quY3Ac7A1BuOM2JvoICraGmjud4y b3EanRnqGIK6iH+VAhhTlV/Owrb2Qm1e13DLxwLp1SocSQl4IrEbF9Y5H3ASdIrE0iFqkpju nPiiHeNhz3LaI5ipjiluKYoH+F6gPx8njHoaDxPePCkSLg4r0IA0afLM74LVZxCRBZEfyRZS J6VVUJefKlz91dWSzR/3xSw/rO4u9Ds/Zh7VBUKy3K+YFryHxRpUek0gSepE1b70Q39L9Sqd M/NZqMvFpwrqgW2Zh2Nh8nqRge90maR4ypBzz3GzLwIDAQABozAwLjAeBgNVHREEFzAVgRNz ZWJzdGVyQHNlYnN0ZXIuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAS1Sk NMgDVzb0ktO9tPPacV0KdKhTYOHcICVmuDEe2sFHOkjLAI1iAKp640pqJEVqvRnfRcCFJ9hK koPjjVZ+ui2rVmJWBG6FSloLRS/YYED4tUAw6DQhK61UOpjkpQxjCdm+5bHG/2ZgJAda1j0x uiN822+xFkcaW/5PQgxSRxcwggMDMIICbKADAgECAhBTfA2qzDbriiQxLX7NFGqlMA0GCSqG SIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QTAeFw0wODA2MzAxMzUxNTdaFw0wOTA2MzAxMzUxNTdaMGgxEDAOBgNVBAQTB3ZhbiBFcmsx EzARBgNVBCoTClNlYmFzdGlhYW4xGzAZBgNVBAMTElNlYmFzdGlhYW4gdmFuIEVyazEiMCAG CSqGSIb3DQEJARYTc2Vic3RlckBzZWJzdGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALCQwwHmB1Zh/xlcYvm4Rcdu3ZoPvvQXYTyX5PJNONbKhKqu6F50dhk+eKrm NwHOwNQbjjNib6CAq2hpo7neMm9xGp0Z6hiCuoh/lQIYU5VfzsK29kJtXtdwy8cC6dUqHEkJ eCKxGxfWOR9wEnSKxNIhapKY7pz4oh3jYc9y2iOYqY4pbimKB/heoD8fJ4x6Gg8T3jwpEi4O K9CANGnyzO+C1WcQkQWRH8kWUielVVCXnypc/dXVks0f98UsP6zuLvQ7P2Ye1QVCstyvmBa8 h8UaVHpNIEnqRNW+9EN/S/UqnTPzWajLxacK6oFtmYdjYfJ6kYHvdJmkeMqQc89xsy8CAwEA AaMwMC4wHgYDVR0RBBcwFYETc2Vic3RlckBzZWJzdGVyLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBAEtUpDTIA1c29JLTvbTz2nFdCnSoU2Dh3CAlZrgxHtrBRzpIywCN YgCqeuNKaiRFar0Z30XAhSfYSpKD441Wfrotq1ZiVgRuhUpaC0Uv2GBA+LVAMOg0ISutVDqY 5KUMYwnZvuWxxv9mYCQHWtY9MbojfNtvsRZHGlv+T0IMUkcXMIIDPzCCAqigAwIBAgIBDTAN BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYB Af8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBl cnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYD VQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCA3EwggNtAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAhBTfA2qzDbriiQxLX7NFGqlMAkGBSsOAwIaBQCgggHQMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDIxMDE3NDQ1N1owIwYJKoZI hvcNAQkEMRYEFBEWOINpu5LPxx9eFFbQ9fmiJ9YLMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFN8DarMNuuKJDEtfs0UaqUwgYcGCyqG SIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECEFN8DarMNuuKJDEtfs0UaqUwDQYJKoZIhvcNAQEBBQAEggEArXEcWa73iMHdN0Uh KTsx8rDUG+AeOfyywTOkKm/Lt1JwPE8GKiVtYZ7l+GOEIcFGkLgGzP3t+hkbY1TErZClo+W2 i568sr+8po9e6CPlR5nt3zH9radKxJe1iGTk8BMJGGa7RTuOn0LuiKbsKnFNTMdCigPyWS1u maTDLlcd/u/bYfSUU5V4uQRx0C9Ld8HVvD1FTM2gbUs5Yi1+hIJ6ARt70RE+eCt8l4bEWdLc A3YOCFPkhcfTXOqsXORUfmzYn7rkonrr6/3OiB6LB+jDrVxGkILs/C/GyvN31TDAXukHaQA4 MGZr1zL+Ee8LaKNw9XbKdm6Xjkp9xWvZHPO/QgAAAAAAAA== --------------ms080309010000010009060007-- From owner-freebsd-scsi@FreeBSD.ORG Tue Feb 10 18:26:34 2009 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C487B1065760 for ; Tue, 10 Feb 2009 18:26:34 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id B9C508FC29 for ; Tue, 10 Feb 2009 18:26:33 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n1AIQTwD053899; Tue, 10 Feb 2009 11:26:29 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4991C6D5.4050400@samsco.org> Date: Tue, 10 Feb 2009 11:26:29 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Sebastiaan van Erk References: <4991BD19.1000409@sebster.com> In-Reply-To: <4991BD19.1000409@sebster.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org Subject: Re: Disk performance on ESXi with FreeBSD 7.1 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 18:26:35 -0000 Sebastiaan van Erk wrote: > Hi, > > I'm running FreeBSD on ESXi but I'm having serious issues with disk > performance, and I'm wondering if it might have something to do with the > scsi driver (or the virtual hardware not returning proper values for its > capabilities or something).. > > I have both a FreeBSD-amd64 and Linux Ubuntu 8.10-amd64 virtual machine > (8GB disk, 512MB RAM, 2-CPU) and run dbench on both of them. The linux > machine is out of the box, not optimized for vmware, > VMI/paravirtualization is off, as is VMotion. The results for dbench > are as follows: > > 1 2 4 > freebsd 12.0009 13.6348 12.9402 (MB/s) > linux 376.145 651.314 634.649 (MB/s) > > Thus there is approx a factor 30 difference for dbench 1, and I cannot > imagine linux being that much faster just due to some performance tuning > kernel parameters. > > I tried both the VMware LSI Logic controller and the BusLogic > controller. Here is the relevant dmesg output of both: > > LSI: > mpt0: port 0x1080-0x10ff mem > 0xf4810000-0xf4810fff irq 17 at device 16.0 on pci0 > mpt0: [ITHREAD] > mpt0: MPI Version=1.2.0.0 > da0 at mpt0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 3.300MB/s transfers > da0: 8192MB (16777216 512 byte sectors: 255H 63S/T 1044C) > > BusLogic: > bt0: port 0x1060-0x107f mem > 0xf4810000-0xf481001f irq 17 at device 16.0 on pci0 > bt0: BT-958 FW Rev. 5.07B Ultra Wide SCSI Host Adapter, SCSI ID 7, 192 CCBs > bt0: [GIANT-LOCKED] > bt0: [ITHREAD] > da0 at bt0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.000MB/s transfers (20.000MHz DT, offset 15, 16bit) > da0: 8192MB (16777216 512 byte sectors: 255H 63S/T 1044C) > > Something that I noticed was the extremely slow transfer rates mentioned > with the da0 device. > > When I'm running dbench the server is not very busy: > > CPU: 0.2% user, 0.0% nice, 6.4% system, 0.7% interrupt, 92.7% idle > 1172 root 1 -8 0 4604K 1228K biowr 1 0:41 4.98% dbench > > I really want to get this working because I want to run a big production > site on FreeBSD. But currently the disk speed is just unworkable. > > I was wondering if anybody had any ideas about how to get proper disk > speeds on FreeBSD, making it a viable guest operating system. > > If any other info is needed, I'm willing to invest quite some time to > provide it! > > Regards, > Sebastiaan Run the following command: sudo camcontrol tags da0 If it returns something like this: (pass0:mpt0:0:0:0): device openings: 1 then run the following command: sudo camcontrol tags da0 -N 64 If this works in improving performance, it can be put into a startup script. I have no idea why the controller is misbehaving with this yet, but I'm working on it. Scott From owner-freebsd-scsi@FreeBSD.ORG Tue Feb 10 18:57:09 2009 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B53D106564A for ; Tue, 10 Feb 2009 18:57:09 +0000 (UTC) (envelope-from sebster@sebster.com) Received: from mail.sebster.com (mail.sebster.com [193.46.80.82]) by mx1.freebsd.org (Postfix) with SMTP id B37EE8FC14 for ; Tue, 10 Feb 2009 18:57:08 +0000 (UTC) (envelope-from sebster@sebster.com) Received: (qmail 77984 invoked from network); 10 Feb 2009 18:57:07 -0000 Received: from unknown (HELO ?10.0.1.6?) (sebster@85.147.225.232) by mail.sebster.com with SMTP; 10 Feb 2009 18:57:06 -0000 Message-ID: <4991CE02.4060202@sebster.com> Date: Tue, 10 Feb 2009 19:57:06 +0100 From: Sebastiaan van Erk User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 CC: freebsd-scsi@freebsd.org References: <4991BD19.1000409@sebster.com> <4991C6D5.4050400@samsco.org> In-Reply-To: <4991C6D5.4050400@samsco.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090203050309080606060301" Subject: Re: Disk performance on ESXi with FreeBSD 7.1 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 18:57:09 -0000 This is a cryptographically signed message in MIME format. --------------ms090203050309080606060301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Scott, >> 1 2 4 >> freebsd 12.0009 13.6348 12.9402 (MB/s) >> linux 376.145 651.314 634.649 (MB/s) >> >> Thus there is approx a factor 30 difference for dbench 1, and I cannot >> imagine linux being that much faster just due to some performance >> tuning kernel parameters. > sudo camcontrol tags da0 > > If it returns something like this: > > (pass0:mpt0:0:0:0): device openings: 1 Yep, exactly that; the bt0 driver returned 2. > then run the following command: > > sudo camcontrol tags da0 -N 64 (pass0:mpt0:0:0:0): tagged openings now 64 (pass0:mpt0:0:0:0): device openings: 64 > If this works in improving performance, it can be put into a startup > script. I have no idea why the controller is misbehaving with this yet, > but I'm working on it. > > Scott Unfortunately I'm still stuck at around 12-14MB/s on both the bt0 and mpt0 controllers, so the performance is not up. Thanks a lot though for the help, if I can do/test anything else, I'm right on it. Regards, Sebastiaan --------------ms090203050309080606060301 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUTCC AwMwggJsoAMCAQICEFN8DarMNuuKJDEtfs0UaqUwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDYzMDEzNTE1N1oX DTA5MDYzMDEzNTE1N1owaDEQMA4GA1UEBBMHdmFuIEVyazETMBEGA1UEKhMKU2ViYXN0aWFh bjEbMBkGA1UEAxMSU2ViYXN0aWFhbiB2YW4gRXJrMSIwIAYJKoZIhvcNAQkBFhNzZWJzdGVy QHNlYnN0ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsJDDAeYHVmH/ GVxi+bhFx27dmg++9BdhPJfk8k041sqEqq7oXnR2GT54quY3Ac7A1BuOM2JvoICraGmjud4y b3EanRnqGIK6iH+VAhhTlV/Owrb2Qm1e13DLxwLp1SocSQl4IrEbF9Y5H3ASdIrE0iFqkpju nPiiHeNhz3LaI5ipjiluKYoH+F6gPx8njHoaDxPePCkSLg4r0IA0afLM74LVZxCRBZEfyRZS J6VVUJefKlz91dWSzR/3xSw/rO4u9Ds/Zh7VBUKy3K+YFryHxRpUek0gSepE1b70Q39L9Sqd M/NZqMvFpwrqgW2Zh2Nh8nqRge90maR4ypBzz3GzLwIDAQABozAwLjAeBgNVHREEFzAVgRNz ZWJzdGVyQHNlYnN0ZXIuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAS1Sk NMgDVzb0ktO9tPPacV0KdKhTYOHcICVmuDEe2sFHOkjLAI1iAKp640pqJEVqvRnfRcCFJ9hK koPjjVZ+ui2rVmJWBG6FSloLRS/YYED4tUAw6DQhK61UOpjkpQxjCdm+5bHG/2ZgJAda1j0x uiN822+xFkcaW/5PQgxSRxcwggMDMIICbKADAgECAhBTfA2qzDbriiQxLX7NFGqlMA0GCSqG SIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QTAeFw0wODA2MzAxMzUxNTdaFw0wOTA2MzAxMzUxNTdaMGgxEDAOBgNVBAQTB3ZhbiBFcmsx EzARBgNVBCoTClNlYmFzdGlhYW4xGzAZBgNVBAMTElNlYmFzdGlhYW4gdmFuIEVyazEiMCAG CSqGSIb3DQEJARYTc2Vic3RlckBzZWJzdGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALCQwwHmB1Zh/xlcYvm4Rcdu3ZoPvvQXYTyX5PJNONbKhKqu6F50dhk+eKrm NwHOwNQbjjNib6CAq2hpo7neMm9xGp0Z6hiCuoh/lQIYU5VfzsK29kJtXtdwy8cC6dUqHEkJ eCKxGxfWOR9wEnSKxNIhapKY7pz4oh3jYc9y2iOYqY4pbimKB/heoD8fJ4x6Gg8T3jwpEi4O K9CANGnyzO+C1WcQkQWRH8kWUielVVCXnypc/dXVks0f98UsP6zuLvQ7P2Ye1QVCstyvmBa8 h8UaVHpNIEnqRNW+9EN/S/UqnTPzWajLxacK6oFtmYdjYfJ6kYHvdJmkeMqQc89xsy8CAwEA AaMwMC4wHgYDVR0RBBcwFYETc2Vic3RlckBzZWJzdGVyLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBAEtUpDTIA1c29JLTvbTz2nFdCnSoU2Dh3CAlZrgxHtrBRzpIywCN YgCqeuNKaiRFar0Z30XAhSfYSpKD441Wfrotq1ZiVgRuhUpaC0Uv2GBA+LVAMOg0ISutVDqY 5KUMYwnZvuWxxv9mYCQHWtY9MbojfNtvsRZHGlv+T0IMUkcXMIIDPzCCAqigAwIBAgIBDTAN BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYB Af8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBl cnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYD VQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCA3EwggNtAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAhBTfA2qzDbriiQxLX7NFGqlMAkGBSsOAwIaBQCgggHQMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDIxMDE4NTcwNlowIwYJKoZI hvcNAQkEMRYEFLFv7irZmkhLMr8nM+/uwMSZWFdBMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFN8DarMNuuKJDEtfs0UaqUwgYcGCyqG SIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECEFN8DarMNuuKJDEtfs0UaqUwDQYJKoZIhvcNAQEBBQAEggEAOhAAX4V11jdrdgNZ VCGWySsH2DsL7Grc7jhOa3xcFvBd/RSorCzaZ6bbylce+++tj+dsk7SahwfRZRUCP+fTcQE1 JGrUXlDMgGEkW6IgSORc2uO5V91Me6a585lpHFKxzO06ljs8QMf+vHfH4HqSSXZ7EX/PW1NT qN6C6qxnIyFs2HPkN5jPeULtcOpLUCASdyG1RYjhOlBkUF1THTcb0jjPEekPxRuFPu4W4mgb IfXosHidm1jGiGX1pPRqx/CVHO3iNG1RzOcJ83Nr5RZnPzmScMpmS/B71cKagflxfOqpgLYn zmvr/3BJeWIHJTCXv2SxC8rt0VToUOheX57G6QAAAAAAAA== --------------ms090203050309080606060301-- From owner-freebsd-scsi@FreeBSD.ORG Wed Feb 11 10:45:11 2009 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14432106579E for ; Wed, 11 Feb 2009 10:45:11 +0000 (UTC) (envelope-from prvs=02938fe137=ob@gruft.de) Received: from obh.snafu.de (v6.gruft.de [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id 915AC8FC1C for ; Wed, 11 Feb 2009 10:45:10 +0000 (UTC) (envelope-from prvs=02938fe137=ob@gruft.de) Received: from ob by obh.snafu.de with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXCab-000Fn4-EB for freebsd-scsi@freebsd.org; Wed, 11 Feb 2009 11:45:09 +0100 Date: Wed, 11 Feb 2009 11:45:09 +0100 From: Oliver Brandmueller To: freebsd-scsi@freebsd.org Message-ID: <20090211104509.GC51761@e-Gitt.NET> References: <4991BD19.1000409@sebster.com> <4991C6D5.4050400@samsco.org> <4991CE02.4060202@sebster.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <4991CE02.4060202@sebster.com> User-Agent: Mutt/1.5.19 (2009-01-05) Sender: Oliver Brandmueller Subject: Re: Disk performance on ESXi with FreeBSD 7.1 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 10:45:11 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Feb 10, 2009 at 07:57:06PM +0100, Sebastiaan van Erk wrote: > Thanks a lot though for the help, if I can do/test anything else, I'm=20 > right on it. Did you try using the ATA instead of SCSI emulation im vmware? I've even=20 seen Linux guests where that helped. I dunno if this thenstill an option=20 for prod for you, however, since ist emulated anyway I don't see reasons=20 why it shouldn't be. - Olli --=20 | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmSrDUACgkQiqtMdzjafymFrQCfQ3Bfu5TCA0xZJXzqPZVMg1t/ xxQAmgLj1MjxJ9to1a7FROnrU8vMcv+z =omzw -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-scsi@FreeBSD.ORG Wed Feb 11 10:48:28 2009 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBE1310657E8 for ; Wed, 11 Feb 2009 10:48:24 +0000 (UTC) (envelope-from sebster@sebster.com) Received: from mail.sebster.com (mail.sebster.com [193.46.80.82]) by mx1.freebsd.org (Postfix) with SMTP id 53DA38FC1E for ; Wed, 11 Feb 2009 10:48:17 +0000 (UTC) (envelope-from sebster@sebster.com) Received: (qmail 90143 invoked from network); 11 Feb 2009 10:48:15 -0000 Received: from unknown (HELO ?10.0.1.6?) (sebster@85.147.225.232) by mail.sebster.com with SMTP; 11 Feb 2009 10:48:15 -0000 Message-ID: <4992ACEE.108@sebster.com> Date: Wed, 11 Feb 2009 11:48:14 +0100 From: Sebastiaan van Erk User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4991BD19.1000409@sebster.com> <4991C6D5.4050400@samsco.org> <4991CE02.4060202@sebster.com> <20090211104509.GC51761@e-Gitt.NET> In-Reply-To: <20090211104509.GC51761@e-Gitt.NET> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080002080205030201010507" Subject: Re: Disk performance on ESXi with FreeBSD 7.1 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 10:48:30 -0000 This is a cryptographically signed message in MIME format. --------------ms080002080205030201010507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit H, Oliver Brandmueller wrote: > Hi, > > On Tue, Feb 10, 2009 at 07:57:06PM +0100, Sebastiaan van Erk wrote: >> Thanks a lot though for the help, if I can do/test anything else, I'm >> right on it. > > Did you try using the ATA instead of SCSI emulation im vmware? I've even > seen Linux guests where that helped. I dunno if this thenstill an option > for prod for you, however, since ist emulated anyway I don't see reasons > why it shouldn't be. As far as I know, this is not an option in ESXi. The only disk controllers you can choose are the LSI Logic and the BusLogic ones, both SCSI. Regards, Sebastiaan > > - Olli > --------------ms080002080205030201010507 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUTCC AwMwggJsoAMCAQICEFN8DarMNuuKJDEtfs0UaqUwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDYzMDEzNTE1N1oX DTA5MDYzMDEzNTE1N1owaDEQMA4GA1UEBBMHdmFuIEVyazETMBEGA1UEKhMKU2ViYXN0aWFh bjEbMBkGA1UEAxMSU2ViYXN0aWFhbiB2YW4gRXJrMSIwIAYJKoZIhvcNAQkBFhNzZWJzdGVy QHNlYnN0ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsJDDAeYHVmH/ GVxi+bhFx27dmg++9BdhPJfk8k041sqEqq7oXnR2GT54quY3Ac7A1BuOM2JvoICraGmjud4y b3EanRnqGIK6iH+VAhhTlV/Owrb2Qm1e13DLxwLp1SocSQl4IrEbF9Y5H3ASdIrE0iFqkpju nPiiHeNhz3LaI5ipjiluKYoH+F6gPx8njHoaDxPePCkSLg4r0IA0afLM74LVZxCRBZEfyRZS J6VVUJefKlz91dWSzR/3xSw/rO4u9Ds/Zh7VBUKy3K+YFryHxRpUek0gSepE1b70Q39L9Sqd M/NZqMvFpwrqgW2Zh2Nh8nqRge90maR4ypBzz3GzLwIDAQABozAwLjAeBgNVHREEFzAVgRNz ZWJzdGVyQHNlYnN0ZXIuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAS1Sk NMgDVzb0ktO9tPPacV0KdKhTYOHcICVmuDEe2sFHOkjLAI1iAKp640pqJEVqvRnfRcCFJ9hK koPjjVZ+ui2rVmJWBG6FSloLRS/YYED4tUAw6DQhK61UOpjkpQxjCdm+5bHG/2ZgJAda1j0x uiN822+xFkcaW/5PQgxSRxcwggMDMIICbKADAgECAhBTfA2qzDbriiQxLX7NFGqlMA0GCSqG SIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QTAeFw0wODA2MzAxMzUxNTdaFw0wOTA2MzAxMzUxNTdaMGgxEDAOBgNVBAQTB3ZhbiBFcmsx EzARBgNVBCoTClNlYmFzdGlhYW4xGzAZBgNVBAMTElNlYmFzdGlhYW4gdmFuIEVyazEiMCAG CSqGSIb3DQEJARYTc2Vic3RlckBzZWJzdGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALCQwwHmB1Zh/xlcYvm4Rcdu3ZoPvvQXYTyX5PJNONbKhKqu6F50dhk+eKrm NwHOwNQbjjNib6CAq2hpo7neMm9xGp0Z6hiCuoh/lQIYU5VfzsK29kJtXtdwy8cC6dUqHEkJ eCKxGxfWOR9wEnSKxNIhapKY7pz4oh3jYc9y2iOYqY4pbimKB/heoD8fJ4x6Gg8T3jwpEi4O K9CANGnyzO+C1WcQkQWRH8kWUielVVCXnypc/dXVks0f98UsP6zuLvQ7P2Ye1QVCstyvmBa8 h8UaVHpNIEnqRNW+9EN/S/UqnTPzWajLxacK6oFtmYdjYfJ6kYHvdJmkeMqQc89xsy8CAwEA AaMwMC4wHgYDVR0RBBcwFYETc2Vic3RlckBzZWJzdGVyLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBAEtUpDTIA1c29JLTvbTz2nFdCnSoU2Dh3CAlZrgxHtrBRzpIywCN YgCqeuNKaiRFar0Z30XAhSfYSpKD441Wfrotq1ZiVgRuhUpaC0Uv2GBA+LVAMOg0ISutVDqY 5KUMYwnZvuWxxv9mYCQHWtY9MbojfNtvsRZHGlv+T0IMUkcXMIIDPzCCAqigAwIBAgIBDTAN BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYB Af8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBl cnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYD VQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCA3EwggNtAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAhBTfA2qzDbriiQxLX7NFGqlMAkGBSsOAwIaBQCgggHQMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDIxMTEwNDgxNFowIwYJKoZI hvcNAQkEMRYEFKLnB23U9NhUVnYkzdPl5caeGHjmMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFN8DarMNuuKJDEtfs0UaqUwgYcGCyqG SIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECEFN8DarMNuuKJDEtfs0UaqUwDQYJKoZIhvcNAQEBBQAEggEAcVQk5rRcLXTljXR7 QDE+6cfq1wjsJNI98kOGgaVnd+xKz+i03JmUuZo1ruoM5wYFveIDQZ+Y4Ca22zj0uOsthcNS v8dJ6bqT5BPNeYGAIFp5Mk68YiavQpwfO4sTnigXnfje1CXE4osStErEpmTIYP1dajcDExrO 5uNkCzEfooxz46FqGLbHcfgo0YIhqbY4ZBvayZs9sA5veqJx1ibVk0kVge5KhqFXtscvVtB6 fyGSZo+Tt7iQfg9PoR7T7wBfKh4nTN+argZwM9PjZqBWwm4pqqml0hVyyFmqKdJnKVbh9Sit kEsp/xTgvT2Ws64UCd1UaZedLWhKimCE9oAX7AAAAAAAAA== --------------ms080002080205030201010507-- From owner-freebsd-scsi@FreeBSD.ORG Wed Feb 11 11:07:55 2009 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 295FE1065873 for ; Wed, 11 Feb 2009 11:07:55 +0000 (UTC) (envelope-from prvs=02938fe137=ob@gruft.de) Received: from obh.snafu.de (v6.gruft.de [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id CF0C68FC1B for ; Wed, 11 Feb 2009 11:07:54 +0000 (UTC) (envelope-from prvs=02938fe137=ob@gruft.de) Received: from ob by obh.snafu.de with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXCwc-000H16-4A for freebsd-scsi@freebsd.org; Wed, 11 Feb 2009 12:07:54 +0100 Date: Wed, 11 Feb 2009 12:07:54 +0100 From: Oliver Brandmueller To: freebsd-scsi@freebsd.org Message-ID: <20090211110753.GD51761@e-Gitt.NET> References: <4991BD19.1000409@sebster.com> <4991C6D5.4050400@samsco.org> <4991CE02.4060202@sebster.com> <20090211104509.GC51761@e-Gitt.NET> <4992ACEE.108@sebster.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rJwd6BRFiFCcLxzm" Content-Disposition: inline In-Reply-To: <4992ACEE.108@sebster.com> User-Agent: Mutt/1.5.19 (2009-01-05) Sender: Oliver Brandmueller Subject: Re: Disk performance on ESXi with FreeBSD 7.1 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 11:08:01 -0000 --rJwd6BRFiFCcLxzm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Feb 11, 2009 at 11:48:14AM +0100, Sebastiaan van Erk wrote: > > Did you try using the ATA instead of SCSI emulation im vmware? I've eve= n=20 > > seen Linux guests where that helped. I dunno if this thenstill an optio= n=20 > > for prod for you, however, since ist emulated anyway I don't see reason= s=20 > > why it shouldn't be. >=20 > As far as I know, this is not an option in ESXi. The only disk=20 > controllers you can choose are the LSI Logic and the BusLogic ones, both= =20 > SCSI. *argh* OK... I've just seen it in vmware server and afaik also in ESX,=20 didn't know about ESXi not offering ATA emulation :-( Sorry. - Olli --=20 | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | --rJwd6BRFiFCcLxzm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmSsYkACgkQiqtMdzjafynFdACfc46t5n3T0hV9Qe5poKA5sSMT qy0AnR730B3FvfUYK/hpgqEC9qSCDrqS =aqPU -----END PGP SIGNATURE----- --rJwd6BRFiFCcLxzm-- From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 12 03:36:32 2009 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92383106566C for ; Thu, 12 Feb 2009 03:36:32 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 497B08FC17 for ; Thu, 12 Feb 2009 03:36:32 +0000 (UTC) (envelope-from spork@bway.net) Received: (qmail 74604 invoked by uid 0); 12 Feb 2009 03:36:31 -0000 Received: from unknown (HELO toasty.nat.fasttrackmonkey.com) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Feb 2009 03:36:31 -0000 Date: Wed, 11 Feb 2009 22:36:30 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@toasty.nat.fasttrackmonkey.com To: Scott Long In-Reply-To: <49911C68.6030203@samsco.org> Message-ID: References: <49911C68.6030203@samsco.org> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-scsi@freebsd.org Subject: Re: 7.1 Panic on degraded disk w/mpt X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 03:36:32 -0000 More info... On Mon, 9 Feb 2009, Scott Long wrote: > Charles Sprickman wrote: >> (posted on -stable already, no takers - added info: full dmesg, crash info >> from panic when array finished rebuilding, some comments on dmesg) >> >> Howdy, >> >> I dug around and can't find a PR on this, and the only other report I saw >> was in this mailing list post that has no replies: >> >> http://www.nabble.com/7.1-BETA2-panic-on-mpt-degrade-td20183173.html >> >> The hardware is a Dell PowerEdge 860 with the Dell/LSI SAS5 controller: >> >> mpt0: port 0xec00-0xecff mem >> 0xfe9fc000-0xfe9fffff,0xfe9e0000-0xfe9effff irq 16 at device 8.0 on pci2 >> mpt0: MPI Version=1.5.13.0 >> >> The panic is repeatable by forcing the array into a degraded state. When >> the array finishes rebuilding, the box also panics. >> >> Here's my best shot at getting info out of kgdb (panic on array going to >> degraded state): > > I wonder if the MPT card is temporarily detaching and then reattaching > the logical drive when the rebuild completes. The info you posted is > inconclusive here. I was able to get it to panic again, and grabbed a picture of the console that includes the output just before the panic. It does appear the device goes away: mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 (mpt0:vol0:1): Physical Disk Status Changed mpt0: mpt_cam_event: 0x15 mpt0: mpt_cam_event: 0x21 (mpt0:vol0:1): Physical Disk Status Changed mpt0:vol0(mpt0:0:0): Volume Status Changed mpt0: mpt_cam_event: 0x15 mpt0: mpt_cam_event: 0x21 mpt0: mpt_cam_event: 0x15 mpt0: mpt_cam_event: 0x21 mpt0:vol0(mpt0:0:0): RAID-1 - Degraded mpt0:vol0(mpt0:0:0): Status ( Enabled ) (mpt0:vol0:1): No longer configured Fatal Trap 12.... blah blah blah Is that information of any use? Does "No longer configured" = device detached? Thanks, Charles > CAM (the FreeBSD SCSI layer) has had some problems handling device > detaches, but we've been very fortunate to have someone examining and > fixing this recently. Would it be possible for you to upgrade to the > most recent 8-CURRENT tree, and re-run your test? If not, I'll see > about generating a patchset against 7.1. > > Scott > From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 13 04:49:52 2009 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADC54106564A for ; Fri, 13 Feb 2009 04:49:52 +0000 (UTC) (envelope-from cowens@greatbaysoftware.com) Received: from portcityweb.com (bayringfw.portcityweb.com [64.140.243.92]) by mx1.freebsd.org (Postfix) with ESMTP id 4EAA28FC18 for ; Fri, 13 Feb 2009 04:49:52 +0000 (UTC) (envelope-from cowens@greatbaysoftware.com) Received: from [127.0.0.1] ([70.88.211.149]) by portcityweb.com with MailEnable ESMTP; Thu, 12 Feb 2009 23:36:50 -0500 X-WatchGuard-Mail-Exception: Allow Message-ID: <4994F940.7070301@greatbaysoftware.com> Date: Thu, 12 Feb 2009 23:38:24 -0500 From: Charles Owens MIME-Version: 1.0 To: Scott Long References: <4991BD19.1000409@sebster.com> <4991C6D5.4050400@samsco.org> In-Reply-To: <4991C6D5.4050400@samsco.org> Content-Type: multipart/mixed; boundary="------------090402000900060509070705" X-WatchGuard-AntiVirus: part scanned. clean action=allow X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-scsi@freebsd.org Subject: Re: Disk performance on ESXi with FreeBSD 7.1 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 04:49:53 -0000 This is a multi-part message in MIME format. --------------090402000900060509070705 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-WatchGuard-AntiVirus: part scanned. clean action=allow Scott Long wrote: > Sebastiaan van Erk wrote: >> Hi, >> >> I'm running FreeBSD on ESXi but I'm having serious issues with disk >> performance, and I'm wondering if it might have something to do with >> the scsi driver (or the virtual hardware not returning proper values >> for its capabilities or something).. >> >> I have both a FreeBSD-amd64 and Linux Ubuntu 8.10-amd64 virtual >> machine (8GB disk, 512MB RAM, 2-CPU) and run dbench on both of them. >> The linux machine is out of the box, not optimized for vmware, >> VMI/paravirtualization is off, as is VMotion. The results for dbench >> are as follows: >> >> 1 2 4 >> freebsd 12.0009 13.6348 12.9402 (MB/s) >> linux 376.145 651.314 634.649 (MB/s) >> >> Thus there is approx a factor 30 difference for dbench 1, and I >> cannot imagine linux being that much faster just due to some >> performance tuning kernel parameters. >> >> I tried both the VMware LSI Logic controller and the BusLogic >> controller. Here is the relevant dmesg output of both: >> >> LSI: >> mpt0: port 0x1080-0x10ff mem >> 0xf4810000-0xf4810fff irq 17 at device 16.0 on pci0 >> mpt0: [ITHREAD] >> mpt0: MPI Version=1.2.0.0 >> da0 at mpt0 bus 0 target 0 lun 0 >> da0: Fixed Direct Access SCSI-2 device >> da0: 3.300MB/s transfers >> da0: 8192MB (16777216 512 byte sectors: 255H 63S/T 1044C) >> >> BusLogic: >> bt0: port 0x1060-0x107f mem >> 0xf4810000-0xf481001f irq 17 at device 16.0 on pci0 >> bt0: BT-958 FW Rev. 5.07B Ultra Wide SCSI Host Adapter, SCSI ID 7, >> 192 CCBs >> bt0: [GIANT-LOCKED] >> bt0: [ITHREAD] >> da0 at bt0 bus 0 target 0 lun 0 >> da0: Fixed Direct Access SCSI-2 device >> da0: 40.000MB/s transfers (20.000MHz DT, offset 15, 16bit) >> da0: 8192MB (16777216 512 byte sectors: 255H 63S/T 1044C) >> >> Something that I noticed was the extremely slow transfer rates >> mentioned with the da0 device. >> >> When I'm running dbench the server is not very busy: >> >> CPU: 0.2% user, 0.0% nice, 6.4% system, 0.7% interrupt, 92.7% idle >> 1172 root 1 -8 0 4604K 1228K biowr 1 0:41 4.98% dbench >> >> I really want to get this working because I want to run a big >> production site on FreeBSD. But currently the disk speed is just >> unworkable. >> >> I was wondering if anybody had any ideas about how to get proper disk >> speeds on FreeBSD, making it a viable guest operating system. >> >> If any other info is needed, I'm willing to invest quite some time to >> provide it! >> >> Regards, >> Sebastiaan > > Run the following command: > > sudo camcontrol tags da0 > > If it returns something like this: > > (pass0:mpt0:0:0:0): device openings: 1 > > then run the following command: > > sudo camcontrol tags da0 -N 64 > > If this works in improving performance, it can be put into a startup > script. I have no idea why the controller is misbehaving with this yet, > but I'm working on it. > > Scott > I'm also seeing poor performance (much less than linux), running within ESX Server... I'm using FreeBSD i386, single CPU, 1 GB RAM. I've run the "camcontrol tags da0 -N 64" command and have seen significant improvement (dbench numbers boosted by factor of 5 or so). Not sure it's quite enough, compared to Linux... but a big help already (thanks!). I'd be glad to do more testing / poking if it could help get this figured out. Thanks, Charles **Charles Owens** *Great Bay Software* --------------090402000900060509070705-- From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 13 13:01:01 2009 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA0901065763 for ; Fri, 13 Feb 2009 13:01:01 +0000 (UTC) (envelope-from cowens@greatbaysoftware.com) Received: from portcityweb.com (bayringfw.portcityweb.com [64.140.243.92]) by mx1.freebsd.org (Postfix) with ESMTP id 6369C8FC43 for ; Fri, 13 Feb 2009 13:01:00 +0000 (UTC) (envelope-from cowens@greatbaysoftware.com) Received: from [127.0.0.1] ([70.88.211.149]) by portcityweb.com with MailEnable ESMTP; Fri, 13 Feb 2009 08:00:57 -0500 X-WatchGuard-Mail-Exception: Allow Message-ID: <49956F66.6080003@greatbaysoftware.com> Date: Fri, 13 Feb 2009 08:02:30 -0500 From: Charles Owens MIME-Version: 1.0 To: Scott Long References: <4991BD19.1000409@sebster.com> <4991C6D5.4050400@samsco.org> <4994F940.7070301@greatbaysoftware.com> In-Reply-To: <4994F940.7070301@greatbaysoftware.com> Content-Type: multipart/mixed; boundary="------------020406080405090000010700" X-WatchGuard-AntiVirus: part scanned. clean action=allow X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-scsi@freebsd.org Subject: Re: Disk performance on ESXi with FreeBSD 7.1 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 13:01:04 -0000 This is a multi-part message in MIME format. --------------020406080405090000010700 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-WatchGuard-AntiVirus: part scanned. clean action=allow Charles Owens wrote: > Scott Long wrote: > >> Sebastiaan van Erk wrote: >> >>> Hi, >>> >>> I'm running FreeBSD on ESXi but I'm having serious issues with disk >>> performance, and I'm wondering if it might have something to do with >>> the scsi driver (or the virtual hardware not returning proper values >>> for its capabilities or something).. >>> >>> ... >>> >> Run the following command: >> >> sudo camcontrol tags da0 >> >> If it returns something like this: >> >> (pass0:mpt0:0:0:0): device openings: 1 >> >> then run the following command: >> >> sudo camcontrol tags da0 -N 64 >> >> If this works in improving performance, it can be put into a startup >> script. I have no idea why the controller is misbehaving with this yet, >> but I'm working on it. >> >> Scott >> >> > I'm also seeing poor performance (much less than linux), running within > ESX Server... I'm using FreeBSD i386, single CPU, 1 GB RAM. > > I've run the "camcontrol tags da0 -N 64" command and have seen > significant improvement (dbench numbers boosted by factor of 5 or so). > Not sure it's quite enough, compared to Linux... but a big help already > (thanks!) Hmmm... my comparison with Linux here was reckless, sorry about that... please consider it withdrawn. What I definitely was seeing was a performance drop between FreeBSD 7.0 and 7.1 -- the CAM "tags" regression that you announced this morning. Thanks for sorting this out! **Charles Owens** *Great Bay Software***** --------------020406080405090000010700-- From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 14 19:03:48 2009 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B1D91065670 for ; Sat, 14 Feb 2009 19:03:48 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id A76D38FC17 for ; Sat, 14 Feb 2009 19:03:47 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n1EJ3hZl079552 for ; Sat, 14 Feb 2009 12:03:43 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4997158F.7050308@samsco.org> Date: Sat, 14 Feb 2009 12:03:43 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: "freebsd-scsi@freebsd.org" X-Enigmail-Version: 0.95.6 Content-Type: multipart/mixed; boundary="------------000106060806060105030700" X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Subject: [Fwd: HEADS UP: Major CAM performance regression] X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 19:03:48 -0000 This is a multi-part message in MIME format. --------------000106060806060105030700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit For those who might not follow the -current and -stable mailing lists. Also, I'm next going to look at the negotiation trouble that domain validation has caused. Scott -------- Original Message -------- Subject: HEADS UP: Major CAM performance regression Date: Fri, 13 Feb 2009 03:55:53 -0700 From: Scott Long To: FreeBSD Current , FreeBSD Stable All, A major performance regression was introduced to the CAM subsystem in FreeBSD 7.1. The following configurations are known to be affected: VMWare ESX VMWare Fusion (using bt or lsilogic controller options) HP CISS RAID Some MPT-SAS combinations with SATA drives attached (Includes Dell SAS5/ir, but not PERC5/PERC6). Pure SCSI and SAS subsystems likely are NOT affected. Any hardware that uses the 'ata' driver is also definitely NOT affected. To determine if your installation is affected, run the following command as root: camcontrol tags da0 Substitute 'da0' with another appropriate drive device number, if needed. Note that this ONLY AFFECTS 'da' DEVICES. If your disks are 'ad' devices, they are NOT affected. The result from running this command should be an output similar to the following: (pass0:mpt0:0:8:0): device openings: 255 If, instead, it reports a value of '1', you are likely affected. Note that it may be normal for USB memory devices to report a low number. Also, many legacy SCSI disks, and devices that are not disks, may also be expected to report a low number. The effect of this problem is that only one I/O command will be issued to the controller and disk at a time, instead of overlapping multiple commands in parallel. This causes significantly higher latency in servicing moderate and heavy I/O workloads, leading to very poor performance. Performance can be easily compared by downgrading to FreeBSD 7.0. I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few days once I've gotten confirmation that the fix works and doesn't cause any adverse side-effects. Anyone wanting to help in this validation effort should apply the attached patch to their kernel source tree and recompile. Please contact me directly by email to report if the problem is fixed for you. If the validation process goes smoothly, I will work with the release engineering team to turn this fix into an official errata update for FreeBSD 7.1. Thanks in advance for your help. Scott --------------000106060806060105030700 Content-Type: text/x-diff; name="cam_tags.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cam_tags.diff" Index: cam_xpt.c =================================================================== --- cam_xpt.c (revision 188569) +++ cam_xpt.c (revision 188570) @@ -6143,10 +6143,9 @@ xpt_schedule(periph, priority); return; } - xpt_release_ccb(done_ccb); - softc->action = PROBE_TUR_FOR_NEGOTIATION; - xpt_schedule(periph, priority); - return; + + csio->data_ptr = NULL; + /* FALLTHROUGH */ } case PROBE_SERIAL_NUM_1: --------------000106060806060105030700--