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 wrote:
> >>
> >>> on 12/07/2012 21:17 Fabian Keil said the following:
> Benjamin Kaduk 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"
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" To: "Steven Hartland" ; 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: 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" To: 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: 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=0xbfebfbff Features2=0x179ae3bf AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16459304960 (15696 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: 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 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: 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: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xf000-0xf03f mem 0xfe00-0xfe3f,0xc000-0xcfff irq 16 at device
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" To: 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: 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=0xbfebfbff Features2=0x179ae3bf AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16459304960 (15696 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: 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 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: 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: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xf000-0xf03f mem 0xfe00-0xfe3f,0xc000-0xcfff irq 16 at device 2.0 on pci0 pci0: at device 22.0 (no driver attached) ehci0: mem 0xfe603000-0xfe6033ff irq 16 at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0: on ehci0 pcib2: irq 17 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 16 at device 28.1 on pci0 pci3: on pcib3 xhci0: mem 0xfe50-0xfe507fff irq 17 at device 0.0 on pci3 xhci0: 32 byte context size. usbus1 on xhci0 pcib4: irq 18 at device 28.2 on pci0 pci4: on pcib4 xhci1: mem 0xfe40-0xfe407fff irq 18 at device 0.0 on pci4 xhci1: 32 byte context size. usbus2 on xhci1 pcib5: irq 19 at device 28.3 on pci0 pci5: on pcib5 re0: port 0xe000-0xe0ff mem 0xd0004000-0xd0004fff,0xd000-0xd0003fff irq 19 at device 0.0 on pci5 re0: Using 1 MSI-X message re0: Chip rev. 0x2c00 re0: MAC rev. 0x miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow,
(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"
