Re: ZFS TRIM support committed to HEAD.
- Original Message - From: Charles Sprickman sp...@bway.net Are you aware of anyone that will be trying this in production, and if so, will you be able to give us list denizens any feedback on it? Yes we've been using it in production for a few months now, but only on single disk pools so not RAIDZ as yet, although we have tested it on such a pool. Thanks so much for porting this… It's not a port this is new code not in any other ZFS implementation, so a FreeBSD first :) Regards Steve 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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
CLANG versus GCC question: compiling non-c99 code with CLANG (clang dumps error)
Hello,
I have a problem and I guess there is a simple solution - at least, I hope.
I try to compile a in spe port which contains some C code that is
definitely Kernighan Ritchie standard like:
--
my_func(win)
Window win;
{
[...]
if ( current-win.data == (lux_data *)NULL ) return;
[...]
}
--
There is no declaration of the return type of the function, I guess it
is implicitely void in older standards, but is treated as non void
function in CLANG - and there the error comes in.
I can compile the code without any problems with GCC 4.6 - without any
change of compiling standard or anything like that, it simply compiles.
I tried to apply CFLAGS+= -std=[c89|gnu89] when compiling with CLANG
since GCC defaults to gnu89 while CLANG defaults to c99 standard, but
this didn't help.
What is the magic switch and where to place it?
Thanks in advance and sorry for the noob question.
Oliver
signature.asc
Description: OpenPGP digital signature
Re: CLANG versus GCC question: compiling non-c99 code with CLANG (clang dumps error)
On 2012-09-24 11:36, O. Hartmann wrote:
I have a problem and I guess there is a simple solution - at least, I hope.
I try to compile a in spe port which contains some C code that is
definitely Kernighan Ritchie standard like:
--
my_func(win)
Window win;
{
[...]
if ( current-win.data == (lux_data *)NULL ) return;
[...]
}
--
There is no declaration of the return type of the function, I guess it
is implicitely void in older standards, but is treated as non void
function in CLANG - and there the error comes in.
Declarations with no type default to int, the infamous implicit int
rule, which apparently is very hard to get rid of. :) I'm not even sure
the committees managed to ditch it in C11...
In any case, in very old C, the 'void' type did not exist; you simply
ignored the return value of such a function.
I can compile the code without any problems with GCC 4.6 - without any
change of compiling standard or anything like that, it simply compiles.
I tried to apply CFLAGS+= -std=[c89|gnu89] when compiling with CLANG
since GCC defaults to gnu89 while CLANG defaults to c99 standard, but
this didn't help.
Unfortunately you did not post the actual error message. What was it?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS TRIM support committed to HEAD.
On Sep 23, 2012, at 6:25 PM, Pawel Jakub Dawidek wrote: On Sun, Sep 23, 2012 at 10:24:53PM +0100, Bob Bishop wrote: Hi, On 23 Sep 2012, at 20:53, Pawel Jakub Dawidek wrote: FYI, I just committed TRIM support to ZFS, especially useful for SSD-only pools. [etc] Is any of this applicable to -STABLE or 8.x? I have a patch against stable/8, but not stable/9: http://people.freebsd.org/~pjd/patches/zfstrim8.patch Are you aware of anyone that will be trying this in production, and if so, will you be able to give us list denizens any feedback on it? Thanks so much for porting this… Charles -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS TRIM support committed to HEAD.
- Original Message - From: Charles Sprickman sp...@bway.net I have a patch against stable/8, but not stable/9: http://people.freebsd.org/~pjd/patches/zfstrim8.patch Are you aware of anyone that will be trying this in production, and if so, will you be able to give us list denizens any feedback on it? We've been using a prior version of this patch in production for a few months now on single and mirrored data disks, no problems. We've done very basic testing on RAIDZ, RAIDZ2 RAIDZ3 no problems with the version we had, but this version includes a number of important fixes for RAIDZ contributed by the zfsonlinux guys. We applied the patch to a 8.3-RELEASE based install with additional patches including patches to provide TRIM support for CAM da devices via SATA pass-through including full support for security and identify commands in camcontrol. If anyone would like those as we can provide. Regards Steve 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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Intel Wireless-N 2230 support
Hello! Can anyone tell me about work on supporting this card by iwn(4)? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CLANG versus GCC question: compiling non-c99 code with CLANG (clang dumps error)
Am 09/24/12 11:52, schrieb Dimitry Andric:
On 2012-09-24 11:36, O. Hartmann wrote:
I have a problem and I guess there is a simple solution - at least, I
hope.
I try to compile a in spe port which contains some C code that is
definitely Kernighan Ritchie standard like:
--
my_func(win)
Window win;
{
[...]
if ( current-win.data == (lux_data *)NULL ) return;
[...]
}
--
There is no declaration of the return type of the function, I guess it
is implicitely void in older standards, but is treated as non void
function in CLANG - and there the error comes in.
Declarations with no type default to int, the infamous implicit int
rule, which apparently is very hard to get rid of. :) I'm not even sure
the committees managed to ditch it in C11...
I see, I though this might be the case ... old, old, very old ...
In any case, in very old C, the 'void' type did not exist; you simply
ignored the return value of such a function.
Well, but noadays, the compiler, like CLANG, complains about a return;
in a non-void function.
I discovered only two places in the file in question, so applying void
as a patch should do the workaround ... ?
I can compile the code without any problems with GCC 4.6 - without any
change of compiling standard or anything like that, it simply compiles.
I tried to apply CFLAGS+= -std=[c89|gnu89] when compiling with CLANG
since GCC defaults to gnu89 while CLANG defaults to c99 standard, but
this didn't help.
Unfortunately you did not post the actual error message. What was it?
here it is:
win.c:796:50: error: non-void function 'lux_freedata' should return a
value [-Wreturn-type]
if ( current-win.data == (lux_data *)NULL ) return;
^
win.c:826:1: warning: type specifier missing, defaults to 'int'
[-Wimplicit-int]
lux_freewins()
^~~~
win.c:831:40: error: non-void function 'lux_freewins' should return a
value [-Wreturn-type]
if ( windows == (lux_wins *)NULL ) return;
signature.asc
Description: OpenPGP digital signature
Re: CLANG versus GCC question: compiling non-c99 code with CLANG (clang dumps error)
On 2012-09-24 13:45, O. Hartmann wrote: ... here it is: win.c:796:50: error: non-void function 'lux_freedata' should return a value [-Wreturn-type] if ( current-win.data == (lux_data *)NULL ) return; ^ Some time ago, the clang developers upgraded this from a warning to an error, which is fairly sensible for new code, but maybe not so for c89 and older. I'm not sure if that was a handy choice, but in any case, you can work around it by adding -Wno-return-type to CFLAGS. win.c:826:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] lux_freewins() ^~~~ These warnings can all be ignored for KR code. Or just add -Wno-implicit-int to shut them up. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS TRIM support committed to HEAD.
According to Steven Hartland: We applied the patch to a 8.3-RELEASE based install with additional patches including patches to provide TRIM support for CAM da devices via SATA pass-through including full support for security and identify commands in camcontrol. If anyone would like those as we can provide. That would be indeed very nice. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.net In memoriam to Ondine, our 2nd child: http://ondine.keltia.net/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS TRIM support committed to HEAD.
- Original Message - From: Ollivier Robert robe...@keltia.freenix.fr According to Steven Hartland: We applied the patch to a 8.3-RELEASE based install with additional patches including patches to provide TRIM support for CAM da devices via SATA pass-through including full support for security and identify commands in camcontrol. If anyone would like those as we can provide. That would be indeed very nice. Our current patchset minus the zfstrim one can be found here:- http://blog.multiplay.co.uk/dropzone/freebsd/zfs-trim-patchset83.tbz Of course you'll also need pjd's zfs trim patch set. It expects to be extracted in /usr/src, where it will create a patches subdir. If you then put the zfs trim patch in the same dir and run ./patches/apply.sh you should be good. There's a fare few patches in there, as I've split the various parts into their individual components so its easier to track and submit. The patches include some back ported code that's already committed as well as other little fixes which also have been committed. Notes at the top of each patch file detail what it does and if its been committed. The one to watch is zfs-ashift-fix.patch as that changes how ashift is calculated for a drive (makes it compatible with QUIRKS) but could well cause issues if you booting from a ZFS tank which has a member disk that changes stripsize. If you don't want to risk that, just delete it. It should however be noted that at least on sandforce based disks if your deletes aren't 4k aligned the trim requests will be ignored by the drive, which is what triggered us to create that patch as well as the ssd_quirks.patch Regards Steve 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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS TRIM support committed to HEAD.
Hi, On 23 Sep 2012, at 23:25, Pawel Jakub Dawidek wrote: I have a patch against stable/8, but not stable/9: http://people.freebsd.org/~pjd/patches/zfstrim8.patch Running with that in an otherwise 8-STABLE GENERIC amd64 kernel, I'm getting: kstat.zfs.misc.zio_trim.zio_trim_bytes: 0 kstat.zfs.misc.zio_trim.zio_trim_success: 0 kstat.zfs.misc.zio_trim.zio_trim_unsupported: 0 kstat.zfs.misc.zio_trim.zio_trim_failed: 2742 which doesn't look like it's working. The SSDs are: ad4: 114473MB ADATA SSD S510 120GB 3.3.2 at ata2-master UDMA100 SATA 3Gb/s ad6: 114473MB ADATA SSD S510 120GB 3.3.2 at ata3-master UDMA100 SATA 3Gb/s Any suggestions? Thanks -- Bob Bishop r...@gid.co.uk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS TRIM support committed to HEAD.
- Original Message - From: Bob Bishop r...@gid.co.uk To: Pawel Jakub Dawidek p...@freebsd.org Cc: freebsd-current@freebsd.org; freebsd...@freebsd.org; Steven Hartland kill...@multiplay.co.uk Sent: Monday, September 24, 2012 3:17 PM Subject: Re: ZFS TRIM support committed to HEAD. Hi, On 23 Sep 2012, at 23:25, Pawel Jakub Dawidek wrote: I have a patch against stable/8, but not stable/9: http://people.freebsd.org/~pjd/patches/zfstrim8.patch Running with that in an otherwise 8-STABLE GENERIC amd64 kernel, I'm getting: kstat.zfs.misc.zio_trim.zio_trim_bytes: 0 kstat.zfs.misc.zio_trim.zio_trim_success: 0 kstat.zfs.misc.zio_trim.zio_trim_unsupported: 0 kstat.zfs.misc.zio_trim.zio_trim_failed: 2742 which doesn't look like it's working. The SSDs are: ad4: 114473MB ADATA SSD S510 120GB 3.3.2 at ata2-master UDMA100 SATA 3Gb/s ad6: 114473MB ADATA SSD S510 120GB 3.3.2 at ata3-master UDMA100 SATA 3Gb/s Any suggestions? Thanks Don't think ad supports TRIM, switch to ada (ahci) and you should be good. Although I'm surprised your seeing that many reported failures as it should have disabled it on a pool level after the first few failures. Is it still increasing? Regards Steve 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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS TRIM support committed to HEAD.
Hi, On 24 Sep 2012, at 16:55, Steven Hartland wrote: - Original Message - From: Bob Bishop r...@gid.co.uk To: Pawel Jakub Dawidek p...@freebsd.org Cc: freebsd-current@freebsd.org; freebsd...@freebsd.org; Steven Hartland kill...@multiplay.co.uk Sent: Monday, September 24, 2012 3:17 PM Subject: Re: ZFS TRIM support committed to HEAD. Hi, On 23 Sep 2012, at 23:25, Pawel Jakub Dawidek wrote: I have a patch against stable/8, but not stable/9: http://people.freebsd.org/~pjd/patches/zfstrim8.patch Running with that in an otherwise 8-STABLE GENERIC amd64 kernel, I'm getting: kstat.zfs.misc.zio_trim.zio_trim_bytes: 0 kstat.zfs.misc.zio_trim.zio_trim_success: 0 kstat.zfs.misc.zio_trim.zio_trim_unsupported: 0 kstat.zfs.misc.zio_trim.zio_trim_failed: 2742 which doesn't look like it's working. The SSDs are: ad4: 114473MB ADATA SSD S510 120GB 3.3.2 at ata2-master UDMA100 SATA 3Gb/s ad6: 114473MB ADATA SSD S510 120GB 3.3.2 at ata3-master UDMA100 SATA 3Gb/s Any suggestions? Thanks Don't think ad supports TRIM, switch to ada (ahci) and you should be good. Although I'm surprised your seeing that many reported failures as it should have disabled it on a pool level after the first few failures. Is it still increasing? Yes I'll try switching to ahci -- Bob Bishop r...@gid.co.uk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS TRIM support committed to HEAD.
On Mon, Sep 24, 2012 at 04:55:20PM +0100, Steven Hartland wrote: - Original Message - From: Bob Bishop r...@gid.co.uk To: Pawel Jakub Dawidek p...@freebsd.org Cc: freebsd-current@freebsd.org; freebsd...@freebsd.org; Steven Hartland kill...@multiplay.co.uk Sent: Monday, September 24, 2012 3:17 PM Subject: Re: ZFS TRIM support committed to HEAD. Hi, On 23 Sep 2012, at 23:25, Pawel Jakub Dawidek wrote: I have a patch against stable/8, but not stable/9: http://people.freebsd.org/~pjd/patches/zfstrim8.patch Running with that in an otherwise 8-STABLE GENERIC amd64 kernel, I'm getting: kstat.zfs.misc.zio_trim.zio_trim_bytes: 0 kstat.zfs.misc.zio_trim.zio_trim_success: 0 kstat.zfs.misc.zio_trim.zio_trim_unsupported: 0 kstat.zfs.misc.zio_trim.zio_trim_failed: 2742 which doesn't look like it's working. The SSDs are: ad4: 114473MB ADATA SSD S510 120GB 3.3.2 at ata2-master UDMA100 SATA 3Gb/s ad6: 114473MB ADATA SSD S510 120GB 3.3.2 at ata3-master UDMA100 SATA 3Gb/s Any suggestions? Thanks Don't think ad supports TRIM, switch to ada (ahci) and you should be good. Although I'm surprised your seeing that many reported failures as it should have disabled it on a pool level after the first few failures. Is it still increasing? Note that 'failed' count is increasing, not the 'unsupported' count. We disable TRIM automatically if we get EOPNOTSUPP and ATA is returning some other error(s). -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgpNdLRO6o97M.pgp Description: PGP signature
using ConnectX card as Ethernet (mlxen)
I have a machine running FreeBSD 10.0-CURRENT #0 r240887 amd64 with two ConnectX (InfiniBand) cards. Relevant bits of dmesg and pciconf -lv below. The cards are connected directly to a 10GB Ethernet switch so I need to run them in eth mode rather than ib. Unfortunately they come up in ib mode and I don't know how to change it. The same hardware works fine under CentOS 6.3, though I need to manually set the cards to 'eth' there as well (which I do using a 'connectx_port_config script from Mellanox that twiddles the mlx4_port1 entries under /sys (sysfs). Under FreeBSD I see these sysctls but I can't set them to 'eth' either via /boot/loader.conf or by sysctl after boot, with or without mlxen and/or mlx4ib loaded: sys.device.mlx4_core0.mlx4_port1: ib sys.device.mlx4_core1.mlx4_port1: ib Assuming mlxen is actually supported, how do I configure the card so it will attach? mlx4_core0: mlx4_core mem 0xdfa0-0xdfaf,0xdd80-0xddff irq 32 at device 0.0 on pci4 mlx4_core: Mellanox ConnectX core driver v1.0-ofed1.5.2 (August 4, 2010) mlx4_core: Initializing mlx4_core mlx4_en: Mellanox ConnectX HCA Ethernet driver v1.5.2 (July 2010) mlx4_en mlx4_core0: UDP RSS is not supported on this device. mlx4_core1: mlx4_core mem 0xdf90-0xdf9f,0xdd00-0xdd7f irq 42 at device 0.0 on pci7 mlx4_core: Initializing mlx4_core mlx4_core0@pci0:4:0:0: class=0x0c0600 card=0x002215b3 chip=0x673c15b3 rev=0xb0 hdr=0x00 vendor = 'Mellanox Technologies' device = 'MT26428 [ConnectX VPI PCIe 2.0 5GT/s - IB QDR / 10GigE]' class = serial bus mlx4_core1@pci0:7:0:0: class=0x028000 card=0x001715b3 chip=0x100315b3 rev=0x00 hdr=0x00 vendor = 'Mellanox Technologies' device = 'MT27500 Family [ConnectX-3]' class = network Thanks, JN ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS TRIM support committed to HEAD.
Hi, On 24 Sep 2012, at 16:55, Steven Hartland wrote: Don't think ad supports TRIM, switch to ada (ahci) and you should be good. Switched to AHCI and now looks more plausible: kstat.zfs.misc.zio_trim.zio_trim_bytes: 2173466624 kstat.zfs.misc.zio_trim.zio_trim_success: 13244 kstat.zfs.misc.zio_trim.zio_trim_unsupported: 0 kstat.zfs.misc.zio_trim.zio_trim_failed: 0 I'll report back if anything unpleasant happens. Thanks to all for this. dmesg below FTR -- Bob Bishop r...@gid.co.uk 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 8.3-STABLE #0: Mon Sep 24 14:00:52 BST 2012 r...@seagoon.gid.co.uk:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (1821.67-MHz K8-class CPU) Origin = GenuineIntel Id = 0x106ca Family = 6 Model = 1c Stepping = 10 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=0x40e31dSSE3,DTES64,MON,DS_CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4080594944 (3891 MB) ACPI APIC Table: INTEL D525MW FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP/HT): APIC ID: 3 ioapic0: Changing APIC ID to 8 ioapic0 Version 2.0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 acpi0: INTEL D525MW on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 850 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 acpi_button0: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 vgapci0: VGA-compatible display port 0x20c0-0x20c7 mem 0xf020-0xf027,0xe000-0xefff,0xf010-0xf01f irq 16 at device 2.0 on pci0 agp0: Intel Pineview SVGA controller on vgapci0 agp0: aperture size is 256M, detected 8188k stolen memory pci0: multimedia, HDA at device 27.0 (no driver attached) pcib1: ACPI PCI-PCI bridge at device 28.0 on pci0 pci1: ACPI PCI bus on pcib1 re0: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet port 0x1000-0x10ff mem 0xf0004000-0xf0004fff,0xf000-0xf0003fff irq 16 at device 0.0 on pci1 re0: Using 1 MSI-X message re0: Chip rev. 0x2c00 re0: MAC rev. 0x miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211B media interface PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 38:60:77:30:09:63 re0: [ITHREAD] pcib2: ACPI PCI-PCI bridge at device 28.1 on pci0 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 28.2 on pci0 pci3: ACPI PCI bus on pcib3 pcib4: ACPI PCI-PCI bridge at device 28.3 on pci0 pci4: ACPI PCI bus on pcib4 uhci0: Intel 82801G (ICH7) USB controller USB-A port 0x2080-0x209f irq 23 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0 on uhci0 uhci1: Intel 82801G (ICH7) USB controller USB-B port 0x2060-0x207f irq 19 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1 on uhci1 uhci2: Intel 82801G (ICH7) USB controller USB-C port 0x2040-0x205f irq 18 at device 29.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus2 on uhci2 uhci3: Intel 82801G (ICH7) USB controller USB-D port 0x2020-0x203f irq 16 at device 29.3 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x2f00 usbus3 on uhci3 ehci0: Intel 82801GB/R (ICH7) USB 2.0 controller mem 0xf0284400-0xf02847ff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4 on ehci0 pcib5: ACPI PCI-PCI bridge at device 30.0 on pci0 pci5: ACPI PCI bus on pcib5 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 ahci0: Intel ICH7 AHCI SATA controller port 0x20b8-0x20bf,0x20cc-0x20cf,0x20b0-0x20b7,0x20c8-0x20cb,0x20a0-0x20af mem 0xf0284000-0xf02843ff irq 18 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier not supported ahcich0: AHCI channel at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: AHCI channel at channel 1 on ahci0 ahcich1: [ITHREAD] pci0: serial bus, SMBus at device 31.3 (no driver attached) acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed03fff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 atrtc0: AT realtime clock port
Re: ZFS TRIM support committed to HEAD.
- Original Message - From: Pawel Jakub Dawidek p...@freebsd.org Although I'm surprised your seeing that many reported failures as it should have disabled it on a pool level after the first few failures. Is it still increasing? Note that 'failed' count is increasing, not the 'unsupported' count. We disable TRIM automatically if we get EOPNOTSUPP and ATA is returning some other error(s). Ahh yes looks like ATA supports BIO_DELETE via ATA_CFA_ERASE if the drive announces ATA_PROTO_CFA, so I can only assume this is failing when it shouldn't. Might be nice to investigate what's happening and fix, but as ATA is being replaced by CAM ATA not sure its worth it? Regards Steve 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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS TRIM support committed to HEAD.
Hi, Still seems to be working OK, but: seagoon# zpool status pool: m1 state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scan: scrub repaired 0 in 0h2m with 0 errors on Mon Sep 24 23:52:08 2012 config: NAME STATE READ WRITE CKSUM m1 ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/disk1 ONLINE109M 0 0 gpt/disk0 ONLINE109M 0 0 errors: No known data errors seagoon# sysctl -a |grep _trim kstat.zfs.misc.zio_trim.zio_trim_bytes: 228731904 kstat.zfs.misc.zio_trim.zio_trim_success: 19406 kstat.zfs.misc.zio_trim.zio_trim_unsupported: 0 kstat.zfs.misc.zio_trim.zio_trim_failed: 0 seagoon# No device errors logged in messages, and scrub comes up clean as you can see. The read error count is increasing, but otherwise everything appears to work OK. -- Bob Bishop r...@gid.co.uk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS TRIM support committed to HEAD.
On Mon, Sep 24, 2012 at 1:03 PM, Steven Hartland kill...@multiplay.co.uk wrote: Ahh yes looks like ATA supports BIO_DELETE via ATA_CFA_ERASE if the drive announces ATA_PROTO_CFA, so I can only assume this is failing when it shouldn't. Might be nice to investigate what's happening and fix, but as ATA is being replaced by CAM ATA not sure its worth it? I believe that the code that you are looking at refers to a old command that is only implemented by CompactFlash cards. The ad(4) driver does not currently support the TRIM command. I have an internal patch that implements it for FreeBSD 8.2; if there's interest I could try to dig it out. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS TRIM support committed to HEAD.
- Original Message - From: Ryan Stone Ahh yes looks like ATA supports BIO_DELETE via ATA_CFA_ERASE if the drive announces ATA_PROTO_CFA, so I can only assume this is failing when it shouldn't. Might be nice to investigate what's happening and fix, but as ATA is being replaced by CAM ATA not sure its worth it? I believe that the code that you are looking at refers to a old command that is only implemented by CompactFlash cards. The ad(4) driver does not currently support the TRIM command. I have an internal patch that implements it for FreeBSD 8.2; if there's interest I could try to dig it out. It may well be but that's the only code in ad driver that I can see which sets DISKFLAG_CAN_DELETE and without that geom_disk should trigger EOPNOTSUPP and hence go into the unsupported not the fail case. Regards Steve 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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Call for bge(4) testers
On Fri, Sep 21, 2012 at 08:34:29PM +0900, Wanpeng Qian wrote: On Thu, Sep 20, 2012 at 06:56:09AM +0900, Wanpeng Qian wrote: Hi, On Mon, Sep 17, 2012 at 09:37:21PM +0900, Wanpeng Qian wrote: Hi, here is the dmesg output. bge0: HP NC107i PCIe Gigabit Server Adapter, ASIC rev. 0x5784100 mem 0xfe9f-0xfe9f irq 18 at device 0.0 on pci4 bge0: CHIP ID 0x05784100; ASIC REV 0x5784; CHIP REV 0x57841; PCI-E miibus0: MII bus on bge0 brgphy0: BCM5784 10/100/1000baseT PHY PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto- flow It seems your controller is BCM5784 A1. The latest WIP have one change that may affect its DMA behavior. So it would be good to know how the WIP version works on your box. I update my system to 9-STABLE and using your WIP files. after I reboot the whole system. I cannot find bge anymore. here is the pciconf -lv output. none1@pci0:4:0:0: class=0x02 card=0x705d103c chip=0x165b14e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme BCM5723 Gigabit Ethernet PCIe' class = network subclass = ethernet Hmm, the WIP version didn't remove the chip id so bge(4) may have failed to attach. Could you check any message printed by bge(4) in dmesg output? There is neither message related to bge in the dmesg output. nor ifconfig -a output. anything else I can try ? Does stock bge(4) in latest stable/9 recognize your controller? If the answer is yes, would you post full verbose boot message? I rebuild the kernel without your WIP files. unfortunately it seems 9-STABLE drop the support of this card while 9.0-RELEASE is fine. still no relate bge message in dmesg. here is the output of pciconf -lcbv none1@pci0:4:0:0: class=0x02 card=0x705d103c chip=0x165b14e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme BCM5723 Gigabit Ethernet PCIe' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xfe9f, size 65536, enabled cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 03[40] = VPD cap 09[60] = vendor (length 108) cap 05[50] = MSI supports 1 message, 64 bit cap 10[cc] = PCI-Express 2 endpoint max data 128(256) link x1(x1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0002[13c] = VC 1 max VC0 ecap 0003[160] = Serial 1 d8d385fffeaf9f38 ecap 0004[16c] = unknown 1 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
device atapicam on r240673
Hello, For years I have put 'device atapicam' in my kernel. If my memory serves my well, this was to assist with dvd recording. I must have missed something. Is it now as simple as adding hw.ata.atapi_dma=1 to /boot/loader.conf? cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror vers.c ctfconvert -L VERSION -g vers.o linking kernel.debug atapi-cam.o: In function `atapi_action': /usr/src/sys/dev/ata/atapi-cam.c:436: undefined reference to `ata_controlcmd' /usr/src/sys/dev/ata/atapi-cam.c:651: undefined reference to `ata_queue_request' *** [kernel.debug] Error code 1 Stop in /usr/obj/usr/src/sys/D. *** [buildkernel] Error code 1 Stop in /usr/src. *** [buildkernel] Error code 1 Stop in /usr/src. (132) @ 23:41:19 Darrel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Call for bge(4) testers
I am so sorry, I make a mistake. I exclude bge driver from kernel config sometime before and I totally forgot it! I will try your WIP files later. Regards. Qian Does stock bge(4) in latest stable/9 recognize your controller? If the answer is yes, would you post full verbose boot message? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Call for bge(4) testers
On Mon, Sep 24, 2012 at 9:51 PM, Wanpeng Qian spf72...@rhythm.ocn.ne.jp wrote: I am so sorry, I make a mistake. I exclude bge driver from kernel config sometime before and I totally forgot it! I will try your WIP files later. Ok -- I was holding off based on your earlier reports, but I'll give pyunh@'s files a shot now. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS TRIM support committed to HEAD.
On Tue, Sep 25, 2012 at 12:14:24AM +0100, Bob Bishop wrote: Hi, Still seems to be working OK, but: seagoon# zpool status pool: m1 state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scan: scrub repaired 0 in 0h2m with 0 errors on Mon Sep 24 23:52:08 2012 config: NAME STATE READ WRITE CKSUM m1 ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/disk1 ONLINE109M 0 0 gpt/disk0 ONLINE109M 0 0 errors: No known data errors seagoon# sysctl -a |grep _trim kstat.zfs.misc.zio_trim.zio_trim_bytes: 228731904 kstat.zfs.misc.zio_trim.zio_trim_success: 19406 kstat.zfs.misc.zio_trim.zio_trim_unsupported: 0 kstat.zfs.misc.zio_trim.zio_trim_failed: 0 seagoon# No device errors logged in messages, and scrub comes up clean as you can see. The read error count is increasing, but otherwise everything appears to work OK. Are you sure your world and kernel are in sync? I remember seeing similar problem when my userland was updated. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgpEsD6sK3yL7.pgp Description: PGP signature
