(no subject)
helllo...i'am dedi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: AHCI Timeouts on SATA III with Intel 520 SSDs
Did you get anywhere with this? Seeing a similar thing on some new Patsburg based machines with KINGSTON SSD's on 8.3-RELEASE. Regards Steve - Original Message - From: Caza, Aaron aaron.c...@ca.weatherford.com To: freebsd-hackers@freebsd.org Sent: Monday, February 13, 2012 9:58 PM Subject: AHCI Timeouts on SATA III with Intel 520 SSDs I've got a couple of Intel 520 SSDs that I'm running on an Intel Sandy-bridge based system(Core i5-2500K H67 chipset). Unfortunately, the drives experience AHCI Timeouts when connected to the SATA III ports. If, however, I connect the drives to the SATA-II ports on the same system the drives do not timeout. NCQ is enabled. Below is the complete dmesg showing the issue. For my testing, I'm just using a FreeBSD 9.0 Release (amd64) generic kernel using 'dd if=/dev/ada0 of=/dev/null bs=1m' to exhibit the behavior. The drives, ofcourse, are brand new and again if I run them off the SATA-II ports instead of the SATA-III ports the problem goes away but then so does the performance. Suggestions? gpart show ada0: = 34 234441581 ada0 GPT (111G) 34128 1 freebsd-boot (64k) 162 232783872 2 freebsd-ufs (111G) 2327840341657581- free - (809M) camcontrol identify ada0: pass0: INTEL SSDSC2CW120A3 400i ATA-9 SATA 3.x device pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-9 SATA 3.x device model INTEL SSDSC2CW120A3 firmware revision 400i serial number WWN 5001517bb27d76f7 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 234441648 sectors LBA48 supported 234441648 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM non-rotating Feature Support Enabled Value Vendor read ahead yes yes write cacheyes yes flush cacheyes yes overlapno Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes yes 254/0xFE automatic acoustic management no no media status notification no no power-up in Standbyyes no write-read-verify no no unload yes yes free-fall no no data set management (TRIM) yes dmesg: Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz (3292.59-MHz K8-class CPU) Origin = GenuineIntel Id = 0x206a7 Family = 6 Model = 2a Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x179ae3bfSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,TSCDLT,AESNI,XSAVE,AVX AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16459304960 (15696 MB) Event timer LAPIC quality 600 ACPI APIC Table: Shuttl Shuttle FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: Shuttl Shuttle on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0xf000-0xf03f mem 0xfe00-0xfe3f,0xc000-0xcfff irq 16 at device 2.0 on pci0 pci0: simple comms at device 22.0 (no driver attached) ehci0: EHCI (generic) USB 2.0 controller mem 0xfe603000-0xfe6033ff irq 16 at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0: EHCI (generic) USB 2.0 controller on ehci0 pcib2: ACPI PCI-PCI bridge irq 17 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge irq 16 at device 28.1 on pci0 pci3: ACPI PCI bus on pcib3 xhci0: XHCI (generic) USB 3.0
RE: AHCI Timeouts on SATA III with Intel 520 SSDs
Yes. In my case, the problem turned out to be a marginal SATA-III port on the motherboard which was determined after swapping SSDs, SATA cables, etcetera to finally pin down the problem. When trouble-shooting this issue, I recall googling a particular missive by Alexander Motion in which he indicates these problems are potentially due to any number of hardware-related reasons hence the exhaustive search for the culprit which, as he suggested, did indeed turn out to be the hardware.It's actually rather interesting how borderline hardware can be - the port in question could handle an Intel 510 SSD running at full SATA-III speed but an Intel 520 pushed it over the brink. -Original Message- From: Steven Hartland [mailto:kill...@multiplay.co.uk] Sent: Friday, July 27, 2012 7:52 AM To: Caza, Aaron; freebsd-hackers@freebsd.org Subject: Re: AHCI Timeouts on SATA III with Intel 520 SSDs Did you get anywhere with this? Seeing a similar thing on some new Patsburg based machines with KINGSTON SSD's on 8.3-RELEASE. Regards Steve - Original Message - From: Caza, Aaron aaron.c...@ca.weatherford.com To: freebsd-hackers@freebsd.org Sent: Monday, February 13, 2012 9:58 PM Subject: AHCI Timeouts on SATA III with Intel 520 SSDs I've got a couple of Intel 520 SSDs that I'm running on an Intel Sandy-bridge based system(Core i5-2500K H67 chipset). Unfortunately, the drives experience AHCI Timeouts when connected to the SATA III ports. If, however, I connect the drives to the SATA-II ports on the same system the drives do not timeout. NCQ is enabled. Below is the complete dmesg showing the issue. For my testing, I'm just using a FreeBSD 9.0 Release (amd64) generic kernel using 'dd if=/dev/ada0 of=/dev/null bs=1m' to exhibit the behavior. The drives, ofcourse, are brand new and again if I run them off the SATA-II ports instead of the SATA-III ports the problem goes away but then so does the performance. Suggestions? gpart show ada0: = 34 234441581 ada0 GPT (111G) 34128 1 freebsd-boot (64k) 162 232783872 2 freebsd-ufs (111G) 2327840341657581- free - (809M) camcontrol identify ada0: pass0: INTEL SSDSC2CW120A3 400i ATA-9 SATA 3.x device pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-9 SATA 3.x device model INTEL SSDSC2CW120A3 firmware revision 400i serial number WWN 5001517bb27d76f7 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 234441648 sectors LBA48 supported 234441648 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM non-rotating Feature Support Enabled Value Vendor read ahead yes yes write cacheyes yes flush cacheyes yes overlapno Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes yes 254/0xFE automatic acoustic management no no media status notification no no power-up in Standbyyes no write-read-verify no no unload yes yes free-fall no no data set management (TRIM) yes dmesg: Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz (3292.59-MHz K8-class CPU) Origin = GenuineIntel Id = 0x206a7 Family = 6 Model = 2a Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x179ae3bfSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,TSCDLT,AESNI,XSAVE,AVX AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16459304960 (15696 MB) Event timer LAPIC quality 600 ACPI APIC Table: Shuttl Shuttle FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: Shuttl Shuttle on motherboard acpi0: Power Button (fixed) Timecounter
Re: AHCI Timeouts on SATA III with Intel 520 SSDs
That's very useful and could well be what we have here. I've got two new machines which run the SSD's fine @ SATA 3 on port 1 but an identical disk on port 2 is having issues. If we switch it down to SATA 2 and all is good. So sounds like the next move is to switch the disks round and see if the problem stays with the disk or the port. Here's hoping its the disk or the cable and not the controller. Regards Steve - Original Message - From: Caza, Aaron aaron.c...@ca.weatherford.com To: Steven Hartland kill...@multiplay.co.uk; freebsd-hackers@freebsd.org Sent: Friday, July 27, 2012 5:07 PM Subject: RE: AHCI Timeouts on SATA III with Intel 520 SSDs Yes. In my case, the problem turned out to be a marginal SATA-III port on the motherboard which was determined after swapping SSDs, SATA cables, etcetera to finally pin down the problem. When trouble-shooting this issue, I recall googling a particular missive by Alexander Motion in which he indicates these problems are potentially due to any number of hardware-related reasons hence the exhaustive search for the culprit which, as he suggested, did indeed turn out to be the hardware.It's actually rather interesting how borderline hardware can be - the port in question could handle an Intel 510 SSD running at full SATA-III speed but an Intel 520 pushed it over the brink. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: dtraceall.ko with old nfsclient
On Thu, 2012-07-12 at 12:47 -0700, Andrew Boyer wrote:
On Jul 12, 2012, at 3:39 PM, Andriy Gapon wrote:
on 12/07/2012 22:36 Fabian Keil said the following:
Andriy Gapon a...@freebsd.org wrote:
on 12/07/2012 21:17 Fabian Keil said the following:
Benjamin Kaduk ka...@mit.edu wrote:
On Wed, 11 Jul 2012, Fabian Keil wrote:
I'm using the following modification of Sean's patch:
This way it seems to work as expected:
diff --git a/sys/modules/dtrace/dtraceall/Makefile
b/sys/modules/dtrace/dtraceall/Makefile index 456efd1..628583b 100644
--- a/sys/modules/dtrace/dtraceall/Makefile +++
b/sys/modules/dtrace/dtraceall/Makefile @@ -1,7 +1,7 @@ # $FreeBSD:
src/sys/modules/dtrace/dtraceall/Makefile,v 1.3 2011/04/09 09:07:31 uqs
Exp $
KMOD= dtraceall -SRCS= dtraceall.c opt_compat.h
+SRCS= dtraceall.c opt_compat.h opt_nfs.h
CFLAGS+= -I${.CURDIR}/../../..
If you do cd sys/modules/dtrace/dtraceall make [obj depend] all, does
it compile OK with the above change?
Depends on your expectations I guess. As neither NFS-related option gets
defined, no dependency on either NFS module is registered. The compiler has
no complaints, though.
Interesting. Could you repeat after sufficient cleaning up?
I am not sure where from opt_nfs.h file could come.
Maybe related: check out sys/modules/ipfw/Makefile. It makes its own option
headers for INET and INET6.
-A
--
Andrew Boyer abo...@averesystems.com
I've pondered this on an off for a couple of weeks now. I can clearly
see that if we want compile time dependencies, that's fine, we can make
each nfclient object dependant on the #define. Both are valid cases to
have loaded though, so they shouldn't be conditional on each other as in
my patches.
If one does this however, the module makefile needs to be adjusted like
the ipfw makefile to create an opt_nfs.h with the NFS client defines,
else you will have neither dtrace object available.
There isn't a clear way that I can see to compile dtraceall.ko as a
module if you are doing so outside of the kernel compile though. The
module tree isn't really aware of what you are running, therefore it
would have to compile to load both regardless. Which, if your kernel
doesn't support one or both nfs objects, will cause a kldload failure.
I'm not real clear how to unwind this situation.
Sean
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
