Re: ZFS TRIM support committed to HEAD.
- Original Message - From: "Charles Sprickman" 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" 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 K&R 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" 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 at ata2-master UDMA100 SATA 3Gb/s ad6: 114473MB 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" To: "Pawel Jakub Dawidek" Cc: ; ; "Steven Hartland" 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 at ata2-master UDMA100 SATA 3Gb/s ad6: 114473MB 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" > To: "Pawel Jakub Dawidek" > Cc: ; ; "Steven > Hartland" > 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 at ata2-master UDMA100 SATA 3Gb/s >> ad6: 114473MB 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" > To: "Pawel Jakub Dawidek" > Cc: ; ; "Steven > Hartland" > 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 at ata2-master UDMA100 SATA 3Gb/s > > ad6: 114473MB 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: 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: 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=0xbfebfbff Features2=0x40e31d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4080594944 (3891 MB) ACPI APIC Table: 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 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 acpi0: 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: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x20c0-0x20c7 mem 0xf020-0xf027,0xe000-0xefff,0xf010-0xf01f irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 8188k stolen memory pci0: at device 27.0 (no driver attached) pcib1: at device 28.0 on pci0 pci1: on pcib1 re0: 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: on re0 rgephy0: 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: at device 28.1 on pci0 pci2: on pcib2 pcib3: at device 28.2 on pci0 pci3: on pcib3 pcib4: at device 28.3 on pci0 pci4: on pcib4 uhci0: port 0x2080-0x209f irq 23 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0 on uhci0 uhci1: port 0x2060-0x207f irq 19 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1 on uhci1 uhci2: port 0x2040-0x205f irq 18 at device 29.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus2 on uhci2 uhci3: port 0x2020-0x203f irq 16 at device 29.3 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x2f00 usbus3 on uhci3 ehci0: mem 0xf0284400-0xf02847ff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4 on ehci0 pcib5: at device 30.0 on pci0 pci5: on pcib5 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: 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: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_hpet0: iomem 0xfed0-0xfed03fff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 atrtc0: port 0x70-0x71,0x74-0x77 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 p4tcc0: on cpu0 p4tcc1: on cpu1 p4tcc2: on cpu2 p4tcc3: on cpu3 ZFS filesystem version 5 ZFS storage pool version 28 RTC BIOS diagnostic error 80 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert
Re: ZFS TRIM support committed to HEAD.
- Original Message - From: "Pawel Jakub Dawidek" 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 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: >> >> >> mem >> >> >> 0xfe9f-0xfe9f irq 18 at device 0.0 on pci4 >> >> >> bge0: CHIP ID 0x05784100; ASIC REV 0x5784; CHIP REV 0x57841; PCI-E >> >> >> miibus0: on bge0 >> >> >> brgphy0: 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 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
