uma_zalloc_arg complaining about non-sleepable locks
I have just upgraded to 8-STABLE/amd64 from about 18 hours ago and am now getting regular (the following pair of messages about every minute) compaints as follows: kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable locks held: kernel: exclusive sleep mutex sp_lock (sp_lock) r = 0 (0xff000460bb00) locked @ /usr/src/sys/rpc/svc.c:1098 kernel: KDB: stack backtrace: kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kernel: _witness_debugger() at _witness_debugger+0x2c kernel: witness_warn() at witness_warn+0x2c2 kernel: uma_zalloc_arg() at uma_zalloc_arg+0x29d kernel: nfs_realign() at nfs_realign+0x5f kernel: fha_assign() at fha_assign+0x2d8 kernel: svc_run_internal() at svc_run_internal+0x1ee kernel: svc_thread_start() at svc_thread_start+0xb kernel: fork_exit() at fork_exit+0x112 kernel: fork_trampoline() at fork_trampoline+0xe kernel: --- trap 0xc, rip = 0x80069e04c, rsp = 0x7fffe6d8, rbp = 0x5 --- kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable locks held: kernel: exclusive sleep mutex sp_lock (sp_lock) r = 0 (0xff000460bb00) locked @ /usr/src/sys/rpc/svc.c:1098 kernel: KDB: stack backtrace: kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kernel: _witness_debugger() at _witness_debugger+0x2c kernel: witness_warn() at witness_warn+0x2c2 kernel: uma_zalloc_arg() at uma_zalloc_arg+0x29d kernel: nfs_realign() at nfs_realign+0x5f kernel: fha_assign() at fha_assign+0x2d8 kernel: svc_run_internal() at svc_run_internal+0x1ee kernel: svc_thread_start() at svc_thread_start+0xb kernel: fork_exit() at fork_exit+0x112 kernel: fork_trampoline() at fork_trampoline+0xe kernel: --- trap 0xc, rip = 0x80069e04c, rsp = 0x7fffe6d8, rbp = 0x5 --- It looks like NFS is missing some lock/unlock pairs. Has anyone else seen this? And does anyone have a fix? -- Peter Jeremy pgpG6eQRJNanL.pgp Description: PGP signature
Re: Looking for testers: atacontrol SMART support
On Tue, Jan 26, 2010 at 08:38:26AM +0300, Andrey V. Elsukov wrote: > On 26.01.2010 7:40, Jeremy Chadwick wrote: > >- All of the code was written by hand; that is to say, there is no code > >copied/stolen from smartmontools, as it's released under the GPL. > > Hi, Jeremy. > > Some time ago i've began the same work, but did not finish it because > ENOTIME.. > So, did you look to NetBSD's implementation? As i remember NetBSD has SMART > reporting and testing support in atactl. Nope, I had no idea they had existing code already in their userland utility; I haven't looked at/used NetBSD since 1993. :-) I'll take a peek and see what I see. Thanks for the tip! -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Looking for testers: atacontrol SMART support
On 26.01.2010 7:40, Jeremy Chadwick wrote: - All of the code was written by hand; that is to say, there is no code copied/stolen from smartmontools, as it's released under the GPL. Hi, Jeremy. Some time ago i've began the same work, but did not finish it because ENOTIME.. So, did you look to NetBSD's implementation? As i remember NetBSD has SMART reporting and testing support in atactl. -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em interface slow down on 8.0R
I've been having a similar problem with my network dropping completely on my 8-STABLE gateway/firewall/fileserver. My setup is a little different, as I have re0 and ral0 bridged for LAN, and em0 for WAN. I've just turned off TX checksum offloading to see if that makes any difference. On Mon, Jan 25, 2010 at 1:49 PM, Lars Eggert wrote: > Hi, > > On 2010-1-25, at 19:38, Nick Rogers wrote: > >> On Mon, Jan 25, 2010 at 10:22 AM, Pyun YongHyeon > wrote: > >> I'm not sure you're seeing a checksum offload bug of em(4) but the > >> bug is easily reproducible in VLAN environments. If the issue is > >> gone when you disable TX checksum offloading, see kern/141843 for > >> for more detailed information as well as fix. > >> > > Good to know, but I am having a similar problem on another em(4) > interface that has no VLAN interfaces. > > FYI, I also have these issues without using VLANs, and turning off TSO > fixed them. > > Lars -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Looking for testers: atacontrol SMART support
As mentioned a while back on the list[1], I worked on getting atacontrol to spit out SMART statistics for ATA disks. Specifically, this would be those using the standard ata(4) layer (including ataahci.ko and similar), but not ahci(4) (ahci.ko), which uses ATA/CAM. Output resembles the following: ID# Attribute Name Curr Worst Thrsh Bytes --- - - - - - 1 Raw Read Error Rate 200 20051 00 00 00 00 00 00 3 Spin Up Time 234 22921 53 20 00 00 00 00 4 Start/Stop Count 100 100 0 11 00 00 00 00 00 5 Reallocated Sector Count 200 200 140 00 00 00 00 00 00 7 Seek Error Rate 200 200 0 00 00 00 00 00 00 9 Power On Hours Count 9595 0 9b 0f 00 00 00 00 10 Spin Retry Count 100 253 0 00 00 00 00 00 00 11 Calibration Retry Count 100 253 0 00 00 00 00 00 00 12 Power Cycle Count100 100 0 0c 00 00 00 00 00 192 Power Off Retract Count 200 200 0 0b 00 00 00 00 00 193 Load Cycle Count 200 200 0 11 00 00 00 00 00 194 Temperature 116 113 0 22 00 00 00 00 00 196 Reallocated Event Count 200 200 0 00 00 00 00 00 00 197 Current Pending Sectors 200 200 0 00 00 00 00 00 00 198 * Uncorrected Sector Count 200 200 0 00 00 00 00 00 00 199 UltraDMA CRC Error Count 200 200 0 00 00 00 00 00 00 200 * Write Error Rate 200 200 0 00 00 00 00 00 00 --- - - - - - * = values only updated after a short/long/offline test Things to note: - I've only been testing on RELENG_8 amd64. The code should work on i386, but if something explodes, let me know. I don't recommend patching RELENG_7 or even a RELEASE tag with this. - I did my best to document the SMART "stuff" throughout the source. Much to my disappointment SMART attributes are not part of the ATA or ACS specification; they're mentioned, but attributes and their interpretation are 100% vendor specific. Decoding them will involve examining the smartmontools source, which takes time. This is why there is no smartmontools "RAW_VALUE" equivalent -- the code for that piece simply hasn't been written. Instead, I display the raw bytes associated with each attribute. This should help with debugging (for the time being). I'll work things out... :-) - I've only tested this with WD2000JD and WD1001FALS disks. Those with Seagate, Maxtor, Hitachi/IBM, Fujitsu, Samsung, and others will probably find many of their attributes names appear as "". See below for how you can help improve this situation. - All operations done are read-only (in fact the device is opened in read-only mode). There may be plans down the road to implement things like inducing SMART short/long/offline tests, but for now I want to get attribute support in there. - All of the code was written by hand; that is to say, there is no code copied/stolen from smartmontools, as it's released under the GPL. I'll be putting diffs/patches up at my site[2] as I work on improvements. I won't be maintaining a CHANGES log for now, unless people really want me to keep one. Methodology I use to test: $ cd /some/other/place $ cp -pR /usr/src/sbin/atacontrol . $ patch -p0 < atacontrol-smart-20100125_01.diff $ cd atacontrol $ make $ ./atacontrol smart Let me know if you're interested in helping improve this, and/or if this feature is at all worth being imported into the standard atacontrol(8) utility. For those wanting to help extend the SMART attribute ID-to-name mapping, this is quite easy: install smartmontools and send me the output from "smartctl -a /dev/adXX". I can work out the rest. Thanks. [1]: http://lists.freebsd.org/pipermail/freebsd-stable/2009-December/053464.html [2]: http://jdc.parodius.com/freebsd/atacontrol/ -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
netstat output changes in 8.0?
Before 8.0-RELEASE, if I ran netstat -rn, it listed a separate route for each host on the network, along with its MAC address. For example ... 172.20.172.17 00:02:b3:2f:64:6a UHLW1 105712 1500 vlan172595 172.20.172.20 00:1e:c9:bb:7c:a9 UHLW1 1002 1500 vlan172598 172.20.172.22 00:14:5e:16:bb:b6 UHLW1107 1500 vlan172491 This behavior seems to have changed in 8.0, where now only the locally-assigned IP addresses and related CIDRs are displayed. Is there any way to get this behavior back, perhaps with a new flag that I am not able to find? Or some sysctl? I have a script that was relying on each host's "expire" flag in the routing table to determine when the MAC address first appeared on the network according to ARP. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Loader, MBR and the boot process
On Mon, 2010-01-25 at 09:45 +, Matthew Seaman wrote: > Andriy Gapon wrote: > > on 25/01/2010 04:41 Robert Noland said the following: > >> On Mon, 2010-01-25 at 07:57 +1100, Mark Andrews wrote: > >>> offset The offset of the start of the partition from the beginning > >>> of > >>> the drive in sectors, or * to have bsdlabel calculate the > >>> correct > >>> offset to use (the end of the previous partition plus one, > >>> ignor- > >>> ing partition `c'. For partition `c', * will be interpreted > >>> as > >>> an offset of 0. The first partition should start at offset > >>> 16, > >>> because the first 16 sectors are reserved for metadata. > >> Ok, now this has my attention... My gut feeling right now is that this > >> is a bug in geom_part_bsd. I don't understand why the label isn't > >> protected. (Adding -b 16 when adding the swap partition fixes this) > >> Another project to goes on my list... > >> > >> If anyone knows why this is done like this... please share. > > > > I presume that this is for purely historic reasons. > > > > I believe this has been known about since 5.x days: > >http://www.freebsd.org/cgi/query-pr.cgi?pr=72812 > > As far as I recall, sometime around 6.1-RELEASE this should have been > fixed. It certainly seems to be the case that it is harmless to have > a plain swap partition start at offset 0, but anything else, like encrypted > swap or putting a filesystem there needs the 16 sector offset. When the first partition (whatever it is), starts at offset 0, if you dd into that partition you wipe out the label entirely, which just doesn't make sense to me. Trying to manage this in the file system code and the swap pager or whatever other consumer might make use of the partition seems like madness to me. robert. > Cheers, > > Matthew > -- Robert Noland FreeBSD ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance
On Tue, 26 Jan 2010, Dan Naumov wrote: > CPU-performance-wise, I am not really worried. The current system is > an Atom 330 and even that is a bit overkill for what I do with it and > from what I am seeing, the new Atom D510 used on those boards is a > tiny bit faster. What I want and care about for this system are > reliability, stability, low power use, quietness and fast disk > read/write speeds. I've been hearing some praise of ICH9R and 6 > native SATA ports should be enough for my needs. AFAIK, the Intel > 82574L network cards included on those are also very well supported? You might want to consider an Athlon (maybe underclock it) - the AMD IXP 700/800 south bridge seems to work well with FreeBSD (in my experience). These boards (eg Gigabyte GA-MA785GM-US2H) have 6 SATA ports (one may be eSATA though) and PATA, they seem ideal really.. You can use PATA with CF to boot and connect 5 disks plus a DVD drive. The CPU is not fanless however, but the other stuff is, on the plus side you won't have to worry about CPU power :) Also, the onboard video works well with radeonhd and is quite fast. One other downside is the onboard network isn't great (Realtek) but I put an em card in mine. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: ZFS panic on RELENG_7/i386
On Mon, 25 Jan 2010, Dmitry Morozovsky wrote: DM> PJD> > I had a crash durinc rsync to ZFS today: DM> PJD> DM> PJD> Do you have recent 7-STABLE? Not sure if it was the same before MFC, DM> DM> r...@woozle:/var/crash# uname -a DM> FreeBSD woozle.rinet.ru 7.2-STABLE FreeBSD 7.2-STABLE #4: Mon Dec 14 12:40:43 DM> MSK 2009 ma...@woozle.rinet.ru:/usr/obj/usr/src/sys/WOOZLE i386 DM> DM> I'll update to fresh sources and recheck, thanks. DM> DM> BTW, any thoughts of another topic I started a couple of weeks ago? Well, after updating to fresh system scrub finished without errors, and now rsync is running, now copied 15G out of 150. Thank you! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance
Alexander Motin wrote: Chris Whitehouse wrote: Dan Naumov wrote: CPU-performance-wise, I am not really worried. The current system is an Atom 330 and even that is a bit overkill for what I do with it and from what I am seeing, the new Atom D510 used on those boards is a tiny bit faster. What I want and care about for this system are reliability, stability, low power use, quietness and fast disk read/write speeds. I've been hearing some praise of ICH9R and 6 native SATA ports should be enough for my needs. AFAIK, the Intel 82574L network cards included on those are also very well supported? These might be interesting then www.fit-pc.com The Intel US15W SCH chipset or System Controller Hub as it's called is mentioned in hardware notes for 8.0R and 7.2R but only for snd_hda, I don't know if this means other functions are supported or not. This thread says it is supported http://mail-index.netbsd.org/port-i386/2010/01/03/msg001695.html Intel US15W (SCH) chipset heavily stripped and tuned for netbooks. It has no SATA, only one PATA channel. It is mostly supported by FreeBSD, but with exception of video, which makes it close to useless. it has only one benefit - low power consumption. The intel spec sheet does say single PATA but according to the fit-pc website it has SATA and miniSD. Still as you say without video support it's not much use, which is useful to know as I had been looking at these. Ok I will go away now :O Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance
Chris Whitehouse wrote: > Dan Naumov wrote: >> >> CPU-performance-wise, I am not really worried. The current system is >> an Atom 330 and even that is a bit overkill for what I do with it and >> from what I am seeing, the new Atom D510 used on those boards is a >> tiny bit faster. What I want and care about for this system are >> reliability, stability, low power use, quietness and fast disk >> read/write speeds. I've been hearing some praise of ICH9R and 6 native >> SATA ports should be enough for my needs. AFAIK, the Intel 82574L >> network cards included on those are also very well supported? > > These might be interesting then > www.fit-pc.com > The Intel US15W SCH chipset or System Controller Hub as it's called is > mentioned in hardware notes for 8.0R and 7.2R but only for snd_hda, I > don't know if this means other functions are supported or not. This > thread says it is supported > http://mail-index.netbsd.org/port-i386/2010/01/03/msg001695.html Intel US15W (SCH) chipset heavily stripped and tuned for netbooks. It has no SATA, only one PATA channel. It is mostly supported by FreeBSD, but with exception of video, which makes it close to useless. it has only one benefit - low power consumption. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance
Dan Naumov wrote: CPU-performance-wise, I am not really worried. The current system is an Atom 330 and even that is a bit overkill for what I do with it and from what I am seeing, the new Atom D510 used on those boards is a tiny bit faster. What I want and care about for this system are reliability, stability, low power use, quietness and fast disk read/write speeds. I've been hearing some praise of ICH9R and 6 native SATA ports should be enough for my needs. AFAIK, the Intel 82574L network cards included on those are also very well supported? These might be interesting then www.fit-pc.com The Intel US15W SCH chipset or System Controller Hub as it's called is mentioned in hardware notes for 8.0R and 7.2R but only for snd_hda, I don't know if this means other functions are supported or not. This thread says it is supported http://mail-index.netbsd.org/port-i386/2010/01/03/msg001695.html Chris - Sincerely, Dan Naumov ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS panic on RELENG_7/i386
On Mon, 25 Jan 2010, Pawel Jakub Dawidek wrote: PJD> On Mon, Jan 25, 2010 at 10:04:20PM +0300, Dmitry Morozovsky wrote: PJD> > Dear colleagues, PJD> > PJD> > I had a crash durinc rsync to ZFS today: PJD> PJD> Do you have recent 7-STABLE? Not sure if it was the same before MFC, r...@woozle:/var/crash# uname -a FreeBSD woozle.rinet.ru 7.2-STABLE FreeBSD 7.2-STABLE #4: Mon Dec 14 12:40:43 MSK 2009 ma...@woozle.rinet.ru:/usr/obj/usr/src/sys/WOOZLE i386 I'll update to fresh sources and recheck, thanks. BTW, any thoughts of another topic I started a couple of weeks ago? PJD> probably not, because what you see is impossible in case of source I'm PJD> looking at. At the begining of zfs_fuid_create() function there is a PJD> check: PJD> PJD>if (!zfsvfs->z_use_fuids || !IS_EPHEMERAL(id) || fuid_idx != 0) PJD>return (id); PJD> PJD> And IS_EPHEMERAL() is defined as follows: PJD> PJD>#define IS_EPHEMERAL(x) (0) PJD> PJD> So it will always return here. PJD> PJD> > #3 0xc08e95ce in zfs_fuid_create (zfsvfs=0xc65c4800, id=Unhandled dwarf PJD> > expression opcode 0x93 PJD> > ) PJD> > at PJD> > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_fuid.c:591 PJD> PJD> -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0-RELEASE -> -STABLE and size of /
On Sat, 23 Jan 2010 20:41:59 -0600 Larry Rosenman wrote: > > add the following to /etc/make.conf: > INSTALL_NODEBUG=yes This is useful. Thanks! -- Regards, Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS panic on RELENG_7/i386
On Mon, Jan 25, 2010 at 10:04:20PM +0300, Dmitry Morozovsky wrote: > Dear colleagues, > > I had a crash durinc rsync to ZFS today: Do you have recent 7-STABLE? Not sure if it was the same before MFC, probably not, because what you see is impossible in case of source I'm looking at. At the begining of zfs_fuid_create() function there is a check: if (!zfsvfs->z_use_fuids || !IS_EPHEMERAL(id) || fuid_idx != 0) return (id); And IS_EPHEMERAL() is defined as follows: #define IS_EPHEMERAL(x) (0) So it will always return here. > #3 0xc08e95ce in zfs_fuid_create (zfsvfs=0xc65c4800, id=Unhandled dwarf > expression opcode 0x93 > ) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_fuid.c:591 -- Pawel Jakub Dawidek http://www.wheel.pl p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpGXOZZRCate.pgp Description: PGP signature
ZFS panic on RELENG_7/i386
Dear colleagues, I had a crash durinc rsync to ZFS today: (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc050c688 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc050c965 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc08e95ce in zfs_fuid_create (zfsvfs=0xc65c4800, id=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_fuid.c:591 #4 0xc0910775 in zfs_freebsd_setattr (ap=0xf5baab64) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:2888 #5 0xc06c6292 in VOP_SETATTR_APV (vop=0xc096e560, a=0xf5baab64) at vnode_if.c:583 #6 0xc05918e5 in setfown (td=0xc834fd80, vp=0xcac4b33c, uid=4294967294, gid=0) at vnode_if.h:315 #7 0xc05919bc in kern_lchown (td=0xc834fd80, path=0xbfbfccc8 , pathseg=UIO_USERSPACE, uid=-2, gid=0) at /usr/src/sys/kern/vfs_syscalls.c:2787 #8 0xc0591a4a in lchown (td=0xc834fd80, uap=0xf5baacfc) at /usr/src/sys/kern/vfs_syscalls.c:2770 #9 0xc06b10f5 in syscall (frame=0xf5baad38) at /usr/src/sys/i386/i386/trap.c:1101 #10 0xc0696b90 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:262 Any other info needed? Thanks in advance! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance
On Mon, Jan 25, 2010 at 08:39:01PM +0200, Dan Naumov wrote: > On Mon, Jan 25, 2010 at 8:32 PM, Alexander Motin wrote: > > Dan Naumov wrote: > >> Alexander, since you seem to be experienced in the area, what do you > >> think of these 2 for use in a FreeBSD8 ZFS NAS: > >> > >> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H > >> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H&IPMI=Y > > > > Unluckily I haven't yet touched Atom family close yet, so I can't say > > about it's performance. But higher desktop level (even bit old) ICH9R > > chipset there is IMHO a good option. It is MUCH better then ICH7, often > > used with previous Atoms. If I had nice small Mini-ITX case with 6 drive > > bays, I would definitely look for some board like that to build home > > storage. > > > > -- > > Alexander Motin > > CPU-performance-wise, I am not really worried. The current system is > an Atom 330 and even that is a bit overkill for what I do with it and > from what I am seeing, the new Atom D510 used on those boards is a > tiny bit faster. What I want and care about for this system are > reliability, stability, low power use, quietness and fast disk > read/write speeds. I've been hearing some praise of ICH9R and 6 native > SATA ports should be enough for my needs. AFAIK, the Intel 82574L > network cards included on those are also very well supported? That's just the thing -- I/O transactions, not to mention ZFS itself, are CPU-bound. If you start seeing slow I/O as a result of the Atom's limitations, I don't think there's anything that can be done about it. Choose wisely. :-) WRT the Intel 82574 series: em(4) supports this, just please be sure to run RELENG_8 as there's been em(4) fixes and improvements which RELEASE doesn't have. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/e1000/ If you have issues with the NIC(s), Jack Vogel at Intel can be of great assistance. :-) -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em interface slow down on 8.0R
Hi, On 2010-1-25, at 19:38, Nick Rogers wrote: >> On Mon, Jan 25, 2010 at 10:22 AM, Pyun YongHyeon wrote: >> I'm not sure you're seeing a checksum offload bug of em(4) but the >> bug is easily reproducible in VLAN environments. If the issue is >> gone when you disable TX checksum offloading, see kern/141843 for >> for more detailed information as well as fix. >> > Good to know, but I am having a similar problem on another em(4) interface > that has no VLAN interfaces. FYI, I also have these issues without using VLANs, and turning off TSO fixed them. Lars
Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance
On Mon, Jan 25, 2010 at 8:32 PM, Alexander Motin wrote: > Dan Naumov wrote: >> Alexander, since you seem to be experienced in the area, what do you >> think of these 2 for use in a FreeBSD8 ZFS NAS: >> >> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H >> http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H&IPMI=Y > > Unluckily I haven't yet touched Atom family close yet, so I can't say > about it's performance. But higher desktop level (even bit old) ICH9R > chipset there is IMHO a good option. It is MUCH better then ICH7, often > used with previous Atoms. If I had nice small Mini-ITX case with 6 drive > bays, I would definitely look for some board like that to build home > storage. > > -- > Alexander Motin CPU-performance-wise, I am not really worried. The current system is an Atom 330 and even that is a bit overkill for what I do with it and from what I am seeing, the new Atom D510 used on those boards is a tiny bit faster. What I want and care about for this system are reliability, stability, low power use, quietness and fast disk read/write speeds. I've been hearing some praise of ICH9R and 6 native SATA ports should be enough for my needs. AFAIK, the Intel 82574L network cards included on those are also very well supported? - Sincerely, Dan Naumov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em interface slow down on 8.0R
On Mon, Jan 25, 2010 at 10:22 AM, Pyun YongHyeon wrote: > On Mon, Jan 25, 2010 at 08:25:43AM -0800, Nick Rogers wrote: > > I have not tried toying with any tcp sysctl. I'm not having performance > > problems so much as the interface just stops working entirely, which I > would > > think has nothing to do with the TCP stack when layer 2 is not > functioning? > > > > I'm not sure you're seeing a checksum offload bug of em(4) but the > bug is easily reproducible in VLAN environments. If the issue is > gone when you disable TX checksum offloading, see kern/141843 for > for more detailed information as well as fix. > Good to know, but I am having a similar problem on another em(4) interface that has no VLAN interfaces. > > > I'll give it a shot if I can. For the moment I have had to switch to a > > different (lower performance) network card to get things stable and I > would > > like to be aware of a more concrete driver fix in STABLE before switching > > back my production machines. > > > > On Mon, Jan 25, 2010 at 6:25 AM, Lars Eggert > wrote: > > > > > Hi, > > > > > > have you tried turning off TCP Segmentation Offloading > (net.inet.tcp.tso > > > sysctl)? That fixed performance issues with some em cards for me. > > > > > > Lars > > > > > > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance
Dan Naumov wrote: > Alexander, since you seem to be experienced in the area, what do you > think of these 2 for use in a FreeBSD8 ZFS NAS: > > http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H > http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H&IPMI=Y Unluckily I haven't yet touched Atom family close yet, so I can't say about it's performance. But higher desktop level (even bit old) ICH9R chipset there is IMHO a good option. It is MUCH better then ICH7, often used with previous Atoms. If I had nice small Mini-ITX case with 6 drive bays, I would definitely look for some board like that to build home storage. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em interface slow down on 8.0R
On Mon, Jan 25, 2010 at 08:25:43AM -0800, Nick Rogers wrote: > I have not tried toying with any tcp sysctl. I'm not having performance > problems so much as the interface just stops working entirely, which I would > think has nothing to do with the TCP stack when layer 2 is not functioning? > I'm not sure you're seeing a checksum offload bug of em(4) but the bug is easily reproducible in VLAN environments. If the issue is gone when you disable TX checksum offloading, see kern/141843 for for more detailed information as well as fix. > I'll give it a shot if I can. For the moment I have had to switch to a > different (lower performance) network card to get things stable and I would > like to be aware of a more concrete driver fix in STABLE before switching > back my production machines. > > On Mon, Jan 25, 2010 at 6:25 AM, Lars Eggert wrote: > > > Hi, > > > > have you tried turning off TCP Segmentation Offloading (net.inet.tcp.tso > > sysctl)? That fixed performance issues with some em cards for me. > > > > Lars > > > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance
On Mon, Jan 25, 2010 at 08:02:58PM +0200, Dan Naumov wrote: > On Mon, Jan 25, 2010 at 7:40 PM, Alexander Motin wrote: > > Artem Belevich wrote: > >> aoc-sat2-mv8 was somewhat slower compared to ICH9 or LSI1068 > >> controllers when I tried it with 6 and 8 disks. > >> I think the problem is that MV8 only does 32K per transfer and that > >> does seem to matter when you have 8 drives hooked up to it. I don't > >> have hard numbers, but peak throughput of MV8 with 8-disk raidz2 was > >> noticeably lower than that of LSI1068 in the same configuration. Both > >> LSI1068 and MV2 were on the same PCI-X bus. It could be a driver > >> limitation. The driver for Marvel SATA controllers in NetBSD seems a > >> bit more advanced compared to what's in FreeBSD. > > > > I also wouldn't recommend to use Marvell 88SXx0xx controllers now. While > > potentially they are interesting, lack of documentation and numerous > > hardware bugs make existing FreeBSD driver very limited there. > > > >> I wish intel would make cheap multi-port PCIe SATA card based on their > >> AHCI controllers. > > > > Indeed. Intel on-board AHCI SATA controllers are fastest from all I have > > tested. Unluckily, they are not producing discrete versions. :( > > > > Now, if discrete solution is really needed, I would still recommend > > SiI3124, but with proper PCI-X 64bit/133MHz bus or built-in PCIe x8 > > bridge. They are fast and have good new siis driver. > > > >> On Mon, Jan 25, 2010 at 3:29 AM, Pete French > >> wrote: > I like to use pci-x with aoc-sat2-mv8 cards or pci-e cardsthat way > you > get a lot more bandwidth.. > >>> I would goalong with that - I have precisely the same controller, with > >>> a pair of eSATA drives, running ZFS mirrored. But I get a nice 100 > >>> meg/second out of them if I try. My controller is, however on PCI-X, not > >>> PCI. It's a shame PCI-X appears to have gone the way of the dinosaur :-( > > > > -- > > Alexander Motin > > Alexander, since you seem to be experienced in the area, what do you > think of these 2 for use in a FreeBSD8 ZFS NAS: > > http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H > http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H&IPMI=Y Any of Supermicro's hardware with an ICH9 will be decent -- but you should remember that there's still a good portion of the I/O transactions which are CPU-bound. The Atom CPU isn't exactly an extensive workhorse. If/once you get one, let me know so I can steal you as a beta tester for getting X7SPA hardware monitoring (fans, external CPU temps, voltages) working in bsdhwmon. :-) -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance
On Mon, Jan 25, 2010 at 7:40 PM, Alexander Motin wrote: > Artem Belevich wrote: >> aoc-sat2-mv8 was somewhat slower compared to ICH9 or LSI1068 >> controllers when I tried it with 6 and 8 disks. >> I think the problem is that MV8 only does 32K per transfer and that >> does seem to matter when you have 8 drives hooked up to it. I don't >> have hard numbers, but peak throughput of MV8 with 8-disk raidz2 was >> noticeably lower than that of LSI1068 in the same configuration. Both >> LSI1068 and MV2 were on the same PCI-X bus. It could be a driver >> limitation. The driver for Marvel SATA controllers in NetBSD seems a >> bit more advanced compared to what's in FreeBSD. > > I also wouldn't recommend to use Marvell 88SXx0xx controllers now. While > potentially they are interesting, lack of documentation and numerous > hardware bugs make existing FreeBSD driver very limited there. > >> I wish intel would make cheap multi-port PCIe SATA card based on their >> AHCI controllers. > > Indeed. Intel on-board AHCI SATA controllers are fastest from all I have > tested. Unluckily, they are not producing discrete versions. :( > > Now, if discrete solution is really needed, I would still recommend > SiI3124, but with proper PCI-X 64bit/133MHz bus or built-in PCIe x8 > bridge. They are fast and have good new siis driver. > >> On Mon, Jan 25, 2010 at 3:29 AM, Pete French >> wrote: I like to use pci-x with aoc-sat2-mv8 cards or pci-e cardsthat way you get a lot more bandwidth.. >>> I would goalong with that - I have precisely the same controller, with >>> a pair of eSATA drives, running ZFS mirrored. But I get a nice 100 >>> meg/second out of them if I try. My controller is, however on PCI-X, not >>> PCI. It's a shame PCI-X appears to have gone the way of the dinosaur :-( > > -- > Alexander Motin Alexander, since you seem to be experienced in the area, what do you think of these 2 for use in a FreeBSD8 ZFS NAS: http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H&IPMI=Y - Sincerely, Dan Naumov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance
Artem Belevich wrote: > aoc-sat2-mv8 was somewhat slower compared to ICH9 or LSI1068 > controllers when I tried it with 6 and 8 disks. > I think the problem is that MV8 only does 32K per transfer and that > does seem to matter when you have 8 drives hooked up to it. I don't > have hard numbers, but peak throughput of MV8 with 8-disk raidz2 was > noticeably lower than that of LSI1068 in the same configuration. Both > LSI1068 and MV2 were on the same PCI-X bus. It could be a driver > limitation. The driver for Marvel SATA controllers in NetBSD seems a > bit more advanced compared to what's in FreeBSD. I also wouldn't recommend to use Marvell 88SXx0xx controllers now. While potentially they are interesting, lack of documentation and numerous hardware bugs make existing FreeBSD driver very limited there. > I wish intel would make cheap multi-port PCIe SATA card based on their > AHCI controllers. Indeed. Intel on-board AHCI SATA controllers are fastest from all I have tested. Unluckily, they are not producing discrete versions. :( Now, if discrete solution is really needed, I would still recommend SiI3124, but with proper PCI-X 64bit/133MHz bus or built-in PCIe x8 bridge. They are fast and have good new siis driver. > On Mon, Jan 25, 2010 at 3:29 AM, Pete French > wrote: >>> I like to use pci-x with aoc-sat2-mv8 cards or pci-e cardsthat way you >>> get a lot more bandwidth.. >> I would goalong with that - I have precisely the same controller, with >> a pair of eSATA drives, running ZFS mirrored. But I get a nice 100 >> meg/second out of them if I try. My controller is, however on PCI-X, not >> PCI. It's a shame PCI-X appears to have gone the way of the dinosaur :-( -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: PCIe audio cards: what is tob be preferred with FreeBSD 8.0/9-CURRENT?
On 01/25/10 04:19, per...@pluto.rain.com wrote: "O. Hartmann" wrote: At this very moment I utilise a M-Audio 5.1 PCI-audio board with which I'm really satisfied. My next box doesn't have PCI slots at all ... I look for the Soundblaster X-Fi range of PCIe cards, It's possible to get an adapter that plugs into a PCIe slot and provides a PCI slot, which might enable you to continue using your current card. I've never actually seen one, so don't know about the mechanics; it could turn out that it can only be used by leaving the cover off of the box :( ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" I gues this is he worst scenario I can imagine. I'd ike to spend some money on a new audio card adapted for PCIe, but it should have support both in FreeBSD and Windows. For mplayer/vlc and so forth my M-Audio audio quality was great. This level should be kept in FreeBSD. Regards Oliver ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance
aoc-sat2-mv8 was somewhat slower compared to ICH9 or LSI1068 controllers when I tried it with 6 and 8 disks. I think the problem is that MV8 only does 32K per transfer and that does seem to matter when you have 8 drives hooked up to it. I don't have hard numbers, but peak throughput of MV8 with 8-disk raidz2 was noticeably lower than that of LSI1068 in the same configuration. Both LSI1068 and MV2 were on the same PCI-X bus. It could be a driver limitation. The driver for Marvel SATA controllers in NetBSD seems a bit more advanced compared to what's in FreeBSD. I wish intel would make cheap multi-port PCIe SATA card based on their AHCI controllers. --Artem On Mon, Jan 25, 2010 at 3:29 AM, Pete French wrote: >> I like to use pci-x with aoc-sat2-mv8 cards or pci-e cardsthat way you >> get a lot more bandwidth.. > > I would goalong with that - I have precisely the same controller, with > a pair of eSATA drives, running ZFS mirrored. But I get a nice 100 > meg/second out of them if I try. My controller is, however on PCI-X, not > PCI. It's a shame PCI-X appears to have gone the way of the dinosaur :-( > > -pete. > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em interface slow down on 8.0R
I have not tried toying with any tcp sysctl. I'm not having performance problems so much as the interface just stops working entirely, which I would think has nothing to do with the TCP stack when layer 2 is not functioning? I'll give it a shot if I can. For the moment I have had to switch to a different (lower performance) network card to get things stable and I would like to be aware of a more concrete driver fix in STABLE before switching back my production machines. On Mon, Jan 25, 2010 at 6:25 AM, Lars Eggert wrote: > Hi, > > have you tried turning off TCP Segmentation Offloading (net.inet.tcp.tso > sysctl)? That fixed performance issues with some em cards for me. > > Lars > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: hald running 100%
On Mon, January 25, 2010 7:20 am, Ruben van Staveren wrote: > > On 13 Nov 2009, at 2:59, Dan Langille wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> After upgrading to 8.0-PRERELEASE today, I'm seeing hald at 100% on both >> my laptop and my desktop: >> >> >> PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND >> 1500 haldaemon 1 1180 22944K 4904K CPU1 1 107:44 100.00% hald >> >> uptime was about 1:50 at this point. >> >> Seems to be relatively common from the posts I've seen. >> > > Did you try to recompile the hald port ? I do not recall. But that sounds familiar. -- Dan Langille -- http://langille.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em interface slow down on 8.0R
Hi, have you tried turning off TCP Segmentation Offloading (net.inet.tcp.tso sysctl)? That fixed performance issues with some em cards for me. Lars On 2010-1-25, at 5:47, Nick Rogers wrote: > I am having similar em interface problems with some of my production > machines running older intel 2-port cards, since upgrading from 7.2-RELEASE > to 8.0-RELEASE. The problem is basically, everything works fine, but > periodically the interface "hangs" (tcpdump shows no frames). A reboot or an > ifconfig down followed by an ifconfig up fixes the problem for some time. > Traffic peaks at maybe 20mbit per day and its all 802.1Q VLAN tagged traffic > (about 10 vlan interfaces). When this happens netstat reports only errors > and no packets on the affected interface. Media is set to autoselect. This > is happening about 5-10x per day. > > Heres relevant sysctl and ifconfig info. > > dev.em.6.%desc: Intel(R) PRO/1000 Network Connection 6.9.14 > dev.em.6.%driver: em > dev.em.6.%location: slot=3 function=0 > dev.em.6.%pnpinfo: vendor=0x8086 device=0x1079 subvendor=0x8086 > subdevice=0x1179 class=0x02 > dev.em.6.%parent: pci3 > dev.em.6.debug: -1 > dev.em.6.stats: -1 > dev.em.6.rx_int_delay: 0 > dev.em.6.tx_int_delay: 66 > dev.em.6.rx_abs_int_delay: 66 > dev.em.6.tx_abs_int_delay: 66 > dev.em.6.rx_processing_limit: 100 > > em6: flags=8843 metric 0 mtu 1500 > options=9b > ether 00:04:23:cd:47:82 > media: Ethernet autoselect (1000baseT ) > status: active > > On Tue, Jan 5, 2010 at 6:35 PM, Jason Chambers wrote: > >> Hiroki Sato wrote: >>> Thank you! I have investigated some more details. First, I got >>> something wrong with the affected FreeBSD versions; one I tried was >>> 8.0-STABLE, not 8.0-RELEASE. So I started to try 8.0R. A summary of >>> chips and releases I tried so far is now the following: >>> >>> 7.2R 8.0R 8.0-STABLE >>> 82540EM (chip=0x100e8086, rev=0x02) OKOKtoo slow[1] >>> 82541PI (chip=0x107c8086, rev=0x05) OK? OK >> >> >> Running 8.0R I've noticed the same problem with this card (0x107c8086). >> Duplex and speed are manually set at full/1000. >> >> >> e...@pci0:3:3:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' >> class = network >> subclass = ethernet >> >> >> Regards, >> >> --Jason >> ___ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ata driver downgrades transfer speed for Intel ICH5 SATA150 in RELENG_8 ?
Kristian Kræmmer Nielsen wrote: > I just updated my kernel from RELEASE_8_0 to RELENG_8 and by rutine I > compare my dmesg -a output to make sure everything still works as expected. > > I notices that the ata-driver suddently downgraded the speed of my Intel > ICH5 SATS150 from SATA150 til UDMA133 - and I am not allowed to change > it manually by using atacontrol. > > Can this have something to do with the recent rewrite of ata-sata.c ? > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-sata.c.diff?r1=1.6.2.2;r2=1.6.2.3 > > Here is the dmesg output compared with RELEASE_8_0 to RELENG_8: > > ...cut out... > atapci1: port > 0xec00-0xec07,0xe800-0xe803,0xe400-0xe407,0xe000-0xe003,0xdc00-0xdc0f > irq 18 at device 31.2 on pci0 > ...cut out... > -ad4: 305245MB at ata2-master SATA150 > +ad4: 305245MB at ata2-master UDMA133 > ...cut out... > -ad6: 305245MB at ata3-master SATA150 > +ad6: 305245MB at ata3-master UDMA133 It is only a cosmetic difference. There is no performance degradation. The reason of this, in inability of the controller driver to get SATA connection speed from this hardware. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0-RELEASE -> -STABLE and size of /
Miroslav Lachman <000.f...@quip.cz> wrote: > Why you are suggesting /var >= 2*RAM? Is it just for saving crash dumps > or anything else? And why so big /tmp? I am running servers with smaller > sizes for years without any problem. Me too. I usually set up a small memory disk for /tmp. I never experienced any serious problems with that. The machine I'm typing this on right now has this line in /etc/fstab: md /tmp mfs rw,nosuid,-s200m,async 0 0 Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Life is short (You need Python)" -- Bruce Eckel, ANSI C++ Comitee member, author of "Thinking in C++" and "Thinking in Java" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em interface slow down on 8.0R
Hi, have you tried turning off TCP Segmentation Offloading (net.inet.tcp.tso sysctl)? That fixed performance issues with some em cards for me. Lars On 2010-1-25, at 5:47, Nick Rogers wrote: > I am having similar em interface problems with some of my production > machines running older intel 2-port cards, since upgrading from 7.2-RELEASE > to 8.0-RELEASE. The problem is basically, everything works fine, but > periodically the interface "hangs" (tcpdump shows no frames). A reboot or an > ifconfig down followed by an ifconfig up fixes the problem for some time. > Traffic peaks at maybe 20mbit per day and its all 802.1Q VLAN tagged traffic > (about 10 vlan interfaces). When this happens netstat reports only errors > and no packets on the affected interface. Media is set to autoselect. This > is happening about 5-10x per day. > > Heres relevant sysctl and ifconfig info. > > dev.em.6.%desc: Intel(R) PRO/1000 Network Connection 6.9.14 > dev.em.6.%driver: em > dev.em.6.%location: slot=3 function=0 > dev.em.6.%pnpinfo: vendor=0x8086 device=0x1079 subvendor=0x8086 > subdevice=0x1179 class=0x02 > dev.em.6.%parent: pci3 > dev.em.6.debug: -1 > dev.em.6.stats: -1 > dev.em.6.rx_int_delay: 0 > dev.em.6.tx_int_delay: 66 > dev.em.6.rx_abs_int_delay: 66 > dev.em.6.tx_abs_int_delay: 66 > dev.em.6.rx_processing_limit: 100 > > em6: flags=8843 metric 0 mtu 1500 > options=9b > ether 00:04:23:cd:47:82 > media: Ethernet autoselect (1000baseT ) > status: active > > On Tue, Jan 5, 2010 at 6:35 PM, Jason Chambers wrote: > >> Hiroki Sato wrote: >>> Thank you! I have investigated some more details. First, I got >>> something wrong with the affected FreeBSD versions; one I tried was >>> 8.0-STABLE, not 8.0-RELEASE. So I started to try 8.0R. A summary of >>> chips and releases I tried so far is now the following: >>> >>> 7.2R 8.0R 8.0-STABLE >>> 82540EM (chip=0x100e8086, rev=0x02) OKOKtoo slow[1] >>> 82541PI (chip=0x107c8086, rev=0x05) OK? OK >> >> >> Running 8.0R I've noticed the same problem with this card (0x107c8086). >> Duplex and speed are manually set at full/1000. >> >> >> e...@pci0:3:3:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' >> class = network >> subclass = ethernet >> >> >> Regards, >> >> --Jason >> ___ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: hald running 100%
On 13 Nov 2009, at 2:59, Dan Langille wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > After upgrading to 8.0-PRERELEASE today, I'm seeing hald at 100% on both > my laptop and my desktop: > > > PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND > 1500 haldaemon 1 1180 22944K 4904K CPU1 1 107:44 100.00% hald > > uptime was about 1:50 at this point. > > Seems to be relatively common from the posts I've seen. > Did you try to recompile the hald port ? Regards, Ruben PGP.sig Description: This is a digitally signed message part
Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance
> I like to use pci-x with aoc-sat2-mv8 cards or pci-e cardsthat way you > get a lot more bandwidth.. I would goalong with that - I have precisely the same controller, with a pair of eSATA drives, running ZFS mirrored. But I get a nice 100 meg/second out of them if I try. My controller is, however on PCI-X, not PCI. It's a shame PCI-X appears to have gone the way of the dinosaur :-( -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: PCIe audio cards: what is tob be preferred with FreeBSD 8.0/9-CURRENT?
On 24 Jan 2010, at 17:36, O. Hartmann wrote: > At this moment, I look for the Soundblaster X-Fi range of PCIe cards, but I'm > not sure whether they are supported by FreeBSd 8/9. Any suggestions? I'm actually looking for a replacement for my X-Fi (I have the PCI X-Fi Gamer). The sound quality isn't great and it's only supported in Windows. I believe there's an effort going on to get a functioning driver on Linux at the moment. Besides that, the card I have got some proprietary connectors for digital audio that you need to buy some kind of dongle for that dangles outside your case. You can fit a 3.5mm optical jack in the proprietary connector, but the signal isn't SP/DIF - my receiver has no idea what to do with it. The more expensive versions probably don't have that problem, they have plenty of connections for all kinds of signals after all. Alban Hertroys -- Screwing up is the best way to attach something to the ceiling. !DSPAM:74,4b5d7a9e10605695025844! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Extra keys in multimedia keyboard doesn't work
On Sun, 24 Jan 2010 23:47:46 + Krzysztof Dajka wrote: > I did check my keyboard with FreeBSD 7.2 and it wasn't supported either. > Xev also didn't return anything. Di you try this: http://www.freshports.org/misc/hotkeys/ Perhaps it will work? There is also this: http://www.freshports.org/sysutils/usbhotkey/ HTH -- Torfinn ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Loader, MBR and the boot process
Andriy Gapon wrote: on 25/01/2010 04:41 Robert Noland said the following: On Mon, 2010-01-25 at 07:57 +1100, Mark Andrews wrote: offset The offset of the start of the partition from the beginning of the drive in sectors, or * to have bsdlabel calculate the correct offset to use (the end of the previous partition plus one, ignor- ing partition `c'. For partition `c', * will be interpreted as an offset of 0. The first partition should start at offset 16, because the first 16 sectors are reserved for metadata. Ok, now this has my attention... My gut feeling right now is that this is a bug in geom_part_bsd. I don't understand why the label isn't protected. (Adding -b 16 when adding the swap partition fixes this) Another project to goes on my list... If anyone knows why this is done like this... please share. I presume that this is for purely historic reasons. I believe this has been known about since 5.x days: http://www.freebsd.org/cgi/query-pr.cgi?pr=72812 As far as I recall, sometime around 6.1-RELEASE this should have been fixed. It certainly seems to be the case that it is harmless to have a plain swap partition start at offset 0, but anything else, like encrypted swap or putting a filesystem there needs the 16 sector offset. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: su password prompt ti stdout instead of /dev/tty
jhell a écrit : On Sun, 24 Jan 2010 21:57, glen.j.barber@ wrote: Cyrille Lefevre wrote: su password prompt is displayed to *stdout* instead of */dev/tty*. # su user $ su root -c date > /tmp/date 2>&1 (nothing displayed) $ cat /tmp/date Password:su: Sorry $ uname -a FreeBSD freebsd8.my.domain 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 I suppose this is a getpass() problem ? This is intended operation as su(1) may not always be affiliated with a TTY. This leaves it open for a script to chat with much like what samba does with its passwd chat mechanism. well, all other oses (netbsd, openbsd, ubuntu at least) don't do it this way, they all password prompt to /dev/tty instead of stdout. freebsd is the only one which prompt to stdout. Regards, Cyrille Lefevre -- mailto:cyrille.lefevre-li...@laposte.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: su password prompt ti stdout instead of /dev/tty
jhell a écrit : If you mean for the program to appropriately append or overwrite to a file you should ( su user -c 'date >output 2>&1' ) instead no, I wanted the log written by the initiator, not the receiver. Regards, Cyrille Lefevre -- mailto:cyrille.lefevre-li...@laposte.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: su password prompt ti stdout instead of /dev/tty
Glen Barber a écrit : Hi, Cyrille Lefevre wrote: Hi, su password prompt is displayed to *stdout* instead of */dev/tty*. # su user $ su root -c date > /tmp/date 2>&1 (nothing displayed) $ cat /tmp/date Password:su: Sorry $ uname -a FreeBSD freebsd8.my.domain 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 I suppose this is a getpass() problem ? I cannot reproduce this. In fact, su root -c date > /tmp/date hangs waiting for input. in fact, you exactly reproduce what I want, su hangs for input bcoz the password prompt is displayed onto stdout, but you don't know it unless you look at the output file. orion % su root -c date > /tmp/date ^C su: Sorry orion % less /tmp/date Password: orion % Also, you appear to be running an unpatched version of FreeBSD 8.0, subject to the rtld exploit (among a few others). I'd suggest upgrading. don't care, it's a vmware guest for testing. thanks anyway. Regards, Cyrille Lefevre -- mailto:cyrille.lefevre-li...@laposte.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance
It depends on the bandwidth of the bus that it is on and the controller itself. I like to use pci-x with aoc-sat2-mv8 cards or pci-e cardsthat way you get a lot more bandwidth.. On Mon, Jan 25, 2010 at 3:32 AM, Dan Naumov wrote: > On Mon, Jan 25, 2010 at 9:34 AM, Dan Naumov wrote: > > On Mon, Jan 25, 2010 at 7:33 AM, Bob Friesenhahn > > wrote: > >> On Mon, 25 Jan 2010, Dan Naumov wrote: > >>> > >>> I've checked with the manufacturer and it seems that the Sil3124 in > >>> this NAS is indeed a PCI card. More info on the card in question is > >>> available at > >>> http://green-pcs.co.uk/2009/01/28/tranquil-bbs2-those-pci-cards/ > >>> I have the card described later on the page, the one with 4 SATA ports > >>> and no eSATA. Alright, so it being PCI is probably a bottleneck in > >>> some ways, but that still doesn't explain the performance THAT bad, > >>> considering that same hardware, same disks, same disk controller push > >>> over 65mb/s in both reads and writes in Win2008. And agian, I am > >>> pretty sure that I've had "close to expected" results when I was > >> > >> The slow PCI bus and this card look like the bottleneck to me. Remember > that > >> your Win2008 tests were with just one disk, your zfs performance with > just > >> one disk was similar to Win2008, and your zfs performance with a mirror > was > >> just under 1/2 that. > >> > >> I don't think that your performance results are necessarily out of line > for > >> the hardware you are using. > >> > >> On an old Sun SPARC workstation with retrofitted 15K RPM drives on > Ultra-160 > >> SCSI channel, I see a zfs mirror write performance of 67,317KB/second > and a > >> read performance of 124,347KB/second. The drives themselves are capable > of > >> 100MB/second range performance. Similar to yourself, I see 1/2 the write > >> performance due to bandwidth limitations. > >> > >> Bob > > > > There is lots of very sweet irony in my particular situiation. > > Initially I was planning to use a single X25-M 80gb SSD in the > > motherboard sata port for the actual OS installation as well as to > > dedicate 50gb of it to a become a designaed L2ARC vdev for my ZFS > > mirrors. The SSD attached to the motherboard port would be recognized > > only as a SATA150 device for some reason, but I was still seeing > > 150mb/s throughput and sub 0.1 ms latencies on that disk simply > > because of how crazy good the X25-M's are. However I ended up having > > very bad issues with the Icydock 2,5" to 3,5" converter jacket I was > > using to keep/fit the SSD in the system and it would randomly drop > > write IO on heavy load due to bad connectors. Having finally figured > > out the cause of my OS installations to the SSD going belly up during > > applying updates, I decided to move the SSD to my desktop and use it > > there instead, additionally thinking that my perhaps my idea of the > > SSD was crazy overkill for what I need the system to do. Ironically > > now that I am seeing how horrible the performance is when I am > > operating on the mirror through this PCI card, I realize that > > actually, my idea was pretty bloody brilliant, I just didn't really > > know why at the time. > > > > An L2ARC device on the motherboard port would really help me with > > random read IO, but to work around the utterly poor write performance, > > I would also need a dedicaled SLOG ZIL device. The catch is that while > > L2ARC devices and be removed from the pool at will (should the device > > up and die all of a sudden), the dedicated ZILs cannot and currently a > > "missing" ZIL device will render the pool it's included in be unable > > to import and become inaccessible. There is some work happening in > > Solaris to implement removing SLOGs from a pool, but that work hasn't > > yet found it's way in FreeBSD yet. > > > > > > - Sincerely, > > Dan Naumov > > OK final question: if/when I go about adding more disks to the system > and want redundancy, am I right in thinking that: ZFS pool of > disk1+disk2 mirror + disk3+disk4 mirror (a la RAID10) would completely > murder my write and read performance even way below the current 28mb/s > / 50mb/s I am seeing with 2 disks on that PCI controller and that in > order to have the least negative impact, I should simply have 2 > independent mirrors in 2 independent pools (with the 5th disk slot in > the NAS given to a non-redundant single disk running off the one > available SATA port on the motherboard)? > > - Sincerely, > Dan Naumov > ___ > freebsd...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: New zfs/bufwait LOR
On Mon, Jan 25, 2010 at 07:07:00PM +1100, Peter Jeremy wrote: > I had the following crop up recently in 8-STABLE/amd64 from end of > November. It's been reported as kern/143184. Basically, page containing the buffer for read(2) is swapped out. This causes page fault in copyout(9) and entry into vm subsystem while zfs vnode lock is held. If the buffer is backed by e.g. UFS vnode instead of anonymous memory, you would get UFS/zfs LOR. The problem is generic, I am working on the solution in collaboration with Peter Holm, basing on the Jeff Roberson idea. > > lock order reversal: > 1st 0xff002f7fb270 zfs (zfs) @ /usr/src/sys/kern/vfs_vnops.c:533 > 2nd 0xff80803a26e0 bufwait (bufwait) @ /usr/src/sys/vm/vm_pager.c:311 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2c > witness_checkorder() at witness_checkorder+0x66f > __lockmgr_args() at __lockmgr_args+0x475 > initpbuf() at initpbuf+0xb9 > getpbuf() at getpbuf+0xdc > swap_pager_getpages() at swap_pager_getpages+0x1aa > vm_fault() at vm_fault+0x5f7 > trap_pfault() at trap_pfault+0x128 > trap() at trap+0x379 > calltrap() at calltrap+0x8 > --- trap 0xc, rip = 0x8049497b, rsp = 0xff809a427830, rbp = > 0xff809a4278b0 --- > copyout() at copyout+0x3b > dmu_read_uio() at dmu_read_uio+0x98 > zfs_freebsd_read() at zfs_freebsd_read+0x56f > VOP_READ_APV() at VOP_READ_APV+0x44 > vn_read() at vn_read+0x149 > dofileread() at dofileread+0xa1 > kern_readv() at kern_readv+0x60 > read() at read+0x55 > syscall() at syscall+0x1ac > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (3, FreeBSD ELF64, read), rip = 0x8008ce86c, rsp = > 0x7ffeb718, rbp = 0x805b41d18 --- > > -- > Peter Jeremy pgpah9yrbudJP.pgp Description: PGP signature
Re: Loader, MBR and the boot process
on 25/01/2010 04:41 Robert Noland said the following: > On Mon, 2010-01-25 at 07:57 +1100, Mark Andrews wrote: >> offset The offset of the start of the partition from the beginning of >> the drive in sectors, or * to have bsdlabel calculate the >> correct >> offset to use (the end of the previous partition plus one, >> ignor- >> ing partition `c'. For partition `c', * will be interpreted as >> an offset of 0. The first partition should start at offset 16, >> because the first 16 sectors are reserved for metadata. > > Ok, now this has my attention... My gut feeling right now is that this > is a bug in geom_part_bsd. I don't understand why the label isn't > protected. (Adding -b 16 when adding the swap partition fixes this) > Another project to goes on my list... > > If anyone knows why this is done like this... please share. I presume that this is for purely historic reasons. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problematic network performance with Marvell 8072 on HP Probook 4710s
On 12:55 Sun 24 Jan , Pyun YongHyeon wrote: > Last time I checked ttcp, it was broken with threading. So you have > to build ttcp without threading support or use netperf to check > performance numbers. That's bad, this evening I will try with netperf. > It seems you have Yukon Extreme controller and its revision is B0 > which is known to have various silicon bug. How about disabling TX > related offloading?(e.g. ifconfig msk0 -txcsum -tso) Does that make > any difference? It seems that there are no differences. > Given that high rates of silicon bug of Yukon having a detailed > errata information would be great help to analyze the issue. But we > still have no access to the information as well as datasheet. And I bet that there's no specific release date for that information, isn't there? Should I take a look at the other BDSs (or even Linux) to check, for example, if they use specific workarounds for my NIC? Actually I am sure that on Linux it works. Would be any problems with the GPL2 in this case? Best regards -- Emanuele A. Bagnaschi pgpikut9OVaLK.pgp Description: PGP signature
Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance
On Mon, Jan 25, 2010 at 9:34 AM, Dan Naumov wrote: > On Mon, Jan 25, 2010 at 7:33 AM, Bob Friesenhahn > wrote: >> On Mon, 25 Jan 2010, Dan Naumov wrote: >>> >>> I've checked with the manufacturer and it seems that the Sil3124 in >>> this NAS is indeed a PCI card. More info on the card in question is >>> available at >>> http://green-pcs.co.uk/2009/01/28/tranquil-bbs2-those-pci-cards/ >>> I have the card described later on the page, the one with 4 SATA ports >>> and no eSATA. Alright, so it being PCI is probably a bottleneck in >>> some ways, but that still doesn't explain the performance THAT bad, >>> considering that same hardware, same disks, same disk controller push >>> over 65mb/s in both reads and writes in Win2008. And agian, I am >>> pretty sure that I've had "close to expected" results when I was >> >> The slow PCI bus and this card look like the bottleneck to me. Remember that >> your Win2008 tests were with just one disk, your zfs performance with just >> one disk was similar to Win2008, and your zfs performance with a mirror was >> just under 1/2 that. >> >> I don't think that your performance results are necessarily out of line for >> the hardware you are using. >> >> On an old Sun SPARC workstation with retrofitted 15K RPM drives on Ultra-160 >> SCSI channel, I see a zfs mirror write performance of 67,317KB/second and a >> read performance of 124,347KB/second. The drives themselves are capable of >> 100MB/second range performance. Similar to yourself, I see 1/2 the write >> performance due to bandwidth limitations. >> >> Bob > > There is lots of very sweet irony in my particular situiation. > Initially I was planning to use a single X25-M 80gb SSD in the > motherboard sata port for the actual OS installation as well as to > dedicate 50gb of it to a become a designaed L2ARC vdev for my ZFS > mirrors. The SSD attached to the motherboard port would be recognized > only as a SATA150 device for some reason, but I was still seeing > 150mb/s throughput and sub 0.1 ms latencies on that disk simply > because of how crazy good the X25-M's are. However I ended up having > very bad issues with the Icydock 2,5" to 3,5" converter jacket I was > using to keep/fit the SSD in the system and it would randomly drop > write IO on heavy load due to bad connectors. Having finally figured > out the cause of my OS installations to the SSD going belly up during > applying updates, I decided to move the SSD to my desktop and use it > there instead, additionally thinking that my perhaps my idea of the > SSD was crazy overkill for what I need the system to do. Ironically > now that I am seeing how horrible the performance is when I am > operating on the mirror through this PCI card, I realize that > actually, my idea was pretty bloody brilliant, I just didn't really > know why at the time. > > An L2ARC device on the motherboard port would really help me with > random read IO, but to work around the utterly poor write performance, > I would also need a dedicaled SLOG ZIL device. The catch is that while > L2ARC devices and be removed from the pool at will (should the device > up and die all of a sudden), the dedicated ZILs cannot and currently a > "missing" ZIL device will render the pool it's included in be unable > to import and become inaccessible. There is some work happening in > Solaris to implement removing SLOGs from a pool, but that work hasn't > yet found it's way in FreeBSD yet. > > > - Sincerely, > Dan Naumov OK final question: if/when I go about adding more disks to the system and want redundancy, am I right in thinking that: ZFS pool of disk1+disk2 mirror + disk3+disk4 mirror (a la RAID10) would completely murder my write and read performance even way below the current 28mb/s / 50mb/s I am seeing with 2 disks on that PCI controller and that in order to have the least negative impact, I should simply have 2 independent mirrors in 2 independent pools (with the 5th disk slot in the NAS given to a non-redundant single disk running off the one available SATA port on the motherboard)? - Sincerely, Dan Naumov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
New zfs/bufwait LOR
I had the following crop up recently in 8-STABLE/amd64 from end of November. It's been reported as kern/143184. lock order reversal: 1st 0xff002f7fb270 zfs (zfs) @ /usr/src/sys/kern/vfs_vnops.c:533 2nd 0xff80803a26e0 bufwait (bufwait) @ /usr/src/sys/vm/vm_pager.c:311 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2c witness_checkorder() at witness_checkorder+0x66f __lockmgr_args() at __lockmgr_args+0x475 initpbuf() at initpbuf+0xb9 getpbuf() at getpbuf+0xdc swap_pager_getpages() at swap_pager_getpages+0x1aa vm_fault() at vm_fault+0x5f7 trap_pfault() at trap_pfault+0x128 trap() at trap+0x379 calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x8049497b, rsp = 0xff809a427830, rbp = 0xff809a4278b0 --- copyout() at copyout+0x3b dmu_read_uio() at dmu_read_uio+0x98 zfs_freebsd_read() at zfs_freebsd_read+0x56f VOP_READ_APV() at VOP_READ_APV+0x44 vn_read() at vn_read+0x149 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x55 syscall() at syscall+0x1ac Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x8008ce86c, rsp = 0x7ffeb718, rbp = 0x805b41d18 --- -- Peter Jeremy pgplTEgQ6sgMF.pgp Description: PGP signature
