From owner-freebsd-fs@FreeBSD.ORG Mon Jan 22 01:12:25 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7D6516A400 for ; Mon, 22 Jan 2007 01:12:25 +0000 (UTC) (envelope-from ahnjoan@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.224]) by mx1.freebsd.org (Postfix) with ESMTP id 88F4013C47E for ; Mon, 22 Jan 2007 01:12:25 +0000 (UTC) (envelope-from ahnjoan@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so421764nzh for ; Sun, 21 Jan 2007 17:12:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=t6ZGwEQ3Gn83aGw79+41w65pKK5+9yp6BTnuJdyL4/y8+Dq4nL5z1XIsrsWcy5Vit5VTFiXbaSVAlZte3bNJ7lqdKl2M+nfdZMdC8yovzqfd+FLnqHUfgaX60GRLh7JfwgelF02NfDqYCf6tMa9bf11Dgoq3oNJVsjwZ1lxWQ0U= Received: by 10.65.43.5 with SMTP id v5mr6493748qbj.1169428344775; Sun, 21 Jan 2007 17:12:24 -0800 (PST) Received: by 10.65.181.20 with HTTP; Sun, 21 Jan 2007 17:12:24 -0800 (PST) Message-ID: <5e575c8a0701211712t4ea42316we02b03221a901841@mail.gmail.com> Date: Sun, 21 Jan 2007 20:12:24 -0500 From: "Ahnjoan Amous" To: "Scott Long" In-Reply-To: <5e575c8a0701201003j4de54712h6913f0edd62c4ffd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <5e575c8a0701111155l859d0ecif617dbda43cef842@mail.gmail.com> <45A6A138.8090208@samsco.org> <5e575c8a0701111307s5a839b82ra4ba5c45d554d3b9@mail.gmail.com> <45A7551C.5030006@samsco.org> <5e575c8a0701130703y6c528cecoed9019472a4956c8@mail.gmail.com> <5e575c8a0701201003j4de54712h6913f0edd62c4ffd@mail.gmail.com> Cc: freebsd-fs@freebsd.org Subject: Re: aac scsi raid driver performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 01:12:25 -0000 I can not say I understand why, but a CPU upgrade seems to have solved my I/O problems. If you read this thread you will see a fairly consistent test of two concurrent sequential writes to different SCSI devices on the same SCSI channel. This test was to figure out why GEOM mirror writes were so slow, and GEOM mirror tests were to figure out why ggatec/ggated duplication was so slow. I have re-installed my slower CPUs and see the poor IO performance return so I am fairly confident that my conclusion can be supported by testing. FYI =96 Hardware PowerEdge 2650, 2.4G/533/512L2/0L3, 1G ram, PERC 3/Di, 2x36G & 3x300G drive= s I have two identical 2650s in this configuration for testing. The CPU upgrade is a 3.066G/533/512L2/1ML3 For more detail in the difference=85 Old CPU (slow concurrent IO) model number is SL6VL New CPU (fast concurrent IO) model number is SL72G Now on to e-bay to find a couple more of these! Results: My IO speed almost tripled=85 I'm able to get over 55MB/sec to each drive in the concurrent write test on the new CPU, much better than the 20MB/sec to each drive in the same test on the old CPU. Thanks again for all the help. From owner-freebsd-fs@FreeBSD.ORG Mon Jan 22 13:15:38 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CD4DE16A400 for ; Mon, 22 Jan 2007 13:15:38 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: from web30309.mail.mud.yahoo.com (web30309.mail.mud.yahoo.com [209.191.69.71]) by mx1.freebsd.org (Postfix) with SMTP id 7DDA813C4C5 for ; Mon, 22 Jan 2007 13:15:38 +0000 (UTC) (envelope-from arne_woerner@yahoo.com) Received: (qmail 9640 invoked by uid 60001); 22 Jan 2007 13:15:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=j9Lo9h2z7ebX86HpkVVmVQogDiAZrZxs8Bm3zlgJFsrTiZKqP+fcuJscSsITKT92kNfLaxpq/2d2JXo7MmJ4EIvpEnPVCxSOAgz/BtAlwx+ymPf8mwPFAbiifnSqHg3/UKIX4bbXH8ywVkxaEmjW1eIuN3Ttqcmx0uQb+AhZ03A=; X-YMail-OSG: d2NPAw8VM1mnvUQW9IU.VdgOPK.n6nu8_O8DPI5NzGqWUmCFdnCPGIpOmRfbRQecpvvAOhEkU.L8Gh64tZksAwQsQSyMB4UVKOHphq0w69fUeJDKk1E- Received: from [85.212.26.75] by web30309.mail.mud.yahoo.com via HTTP; Mon, 22 Jan 2007 05:15:37 PST Date: Mon, 22 Jan 2007 05:15:37 -0800 (PST) From: "R. B. Riddick" To: freebsd-fs@freebsd.org, CyberLeo Kitsana , FreeBSD Geom MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <916065.8298.qm@web30309.mail.mud.yahoo.com> Cc: Subject: Re: geom_raid5 livelock? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 13:15:38 -0000 --- "R. B. Riddick" wrote: > It looks like, always the same consumer returns false data again and again in > this strange situation, although at the same time a dd to the same consumer > at the same offset returns data, that fits to the parity block. > > Does somebody here have an idea, why GEOM does that? > Could it be, that graid5 ruined somehow memory management? > Could it be, that GEOM is disturbed by simultaneous request? > I think, not graid5 ruined memory management, but UFS changes memory areas while a read request, that has to use the same memory area, is not completed. Hints: 1. Since I use for graid5's SAFEOP mode just graid5-private-memory for the parity check, no parity errors show up. 2. It was always -when I checked it- the use-data memory chunk, that had bad data. 3. That happened in a quite simple special case, too (I used just 2 disks, so that graid5 was like gmirror with 2 disks and round-robin balance). Further details see: http://perforce.freebsd.org/chv.cgi?CH=113310 Anyone here, who can validate my theory (it feels so _wrong_!)? :-) -Arne ____________________________________________________________________________________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ From owner-freebsd-fs@FreeBSD.ORG Mon Jan 22 14:39:11 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6721916A403 for ; Mon, 22 Jan 2007 14:39:11 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id F19C113C45D for ; Mon, 22 Jan 2007 14:39:10 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by nf-out-0910.google.com with SMTP id m19so490553nfc for ; Mon, 22 Jan 2007 06:39:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type; b=R5WHcAuWEssnU9Omncvb1fhXWF3xQU3NlwkeTldLn4rpF7YPJzHoNg+4PMAVshLm5T+n7sEld+devXaFHydTUnYxnlo3Cxo77eWqkk9+sZkplB/JQwEQhP9fr3u3KVPyyJYqPSjRsDUn5CXpWVIjT7G1+At5bQgsOUe8SawkNSA= Received: by 10.49.68.6 with SMTP id v6mr6730835nfk.1169476745654; Mon, 22 Jan 2007 06:39:05 -0800 (PST) Received: from ?192.168.123.202? ( [195.241.221.201]) by mx.google.com with ESMTP id o45sm15385110nfa.2007.01.22.06.39.04; Mon, 22 Jan 2007 06:39:05 -0800 (PST) Message-ID: <45B4CC81.1090607@gmail.com> Date: Mon, 22 Jan 2007 15:38:57 +0100 From: Rene Ladan User-Agent: Thunderbird 1.5.0.9 (X11/20070119) MIME-Version: 1.0 To: fs@freebsd.org X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/mixed; boundary="------------010309030003080904020209" Cc: Subject: xtaf-20070122 available X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 14:39:11 -0000 This is a multi-part message in MIME format. --------------010309030003080904020209 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I put a new version of the XTAF (xbox360 fs) module online at http://home.tiscali.nl/rladan/freebsd/xtaf The patch consists of three parts, you'll need to apply them all (glue-20070119.diff.bz2 , kern-20070122.diff.bz2 (the fs module), user-20070119.diff.bz2 (a new mount binary)). There fs module still contains some nasty bugs, maybe some (msdos)fs or VOP gurus could have a look? My own guess is that I somehow mangle the cluster offsets, resulting in such things as directories showing up as files in ls(1), directories getting skipped, and some files in the root directory showing the wrong contents. Copying this without modifications from the msdosfs module is not possible because Microsoft decided to omit the . and .. directory entries (everywhere, not just in the root directory). I've uploaded an actual xtaf fs from my xbox360 memory card at http://home.tiscali.nl/rladan/freebsd/xtaf/part0.tbz That file also contains some notes about how that file system should look. To test it on a CURRENT box : (download and bunzip2 the files) # cd /usr/src # patch < glue-20070119.diff (same for kern and user) (rebuild world + kernel) (reboot) (get part0.tbz, extract part0.xtaf from it) # mdconfig -a -t vnode -f part0.xtaf # mount_xtaf /dev/mdX /mnt (play with it) Note that write support is currently disabled behind #ifdef XTAF_WRITE Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 --------------010309030003080904020209 Content-Type: text/plain; name="xtaf-20070122.md5.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xtaf-20070122.md5.txt" MD5 (glue-20070119.diff.bz2) = a35e811c8af088b5c35308200ca836b3 size = 1234 MD5 (kern-20070122.diff.bz2) = 74a6917b2b89b63a9ecfc211b5cf832a size = 36351 MD5 (user-20070119.diff.bz2) = a365d8306db02286431a29e0f238ea5b size = 4297 --------------010309030003080904020209-- From owner-freebsd-fs@FreeBSD.ORG Mon Jan 22 14:43:22 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66A9516A401 for ; Mon, 22 Jan 2007 14:43:22 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id 00C3913C442 for ; Mon, 22 Jan 2007 14:43:21 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so993109uge for ; Mon, 22 Jan 2007 06:43:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:content-type:content-transfer-encoding; b=K6Z9u0+RnU7XG5PLG2y6PBXJwxWm0gvsKE7qqqftFHZ4DY0imdTMPQun4BlcQ/gdfbL2UyR/Jxac22yiFxGBbv7NuSoNuPZQ2ABtSxNwnxqjaB8aUVqcpkKkbr8EyYyvhgZ6FvRjAodvb0MT86OMVQH8M7cqIPBuImppVV3QNfA= Received: by 10.67.29.12 with SMTP id g12mr7693050ugj.1169475363679; Mon, 22 Jan 2007 06:16:03 -0800 (PST) Received: from ?192.168.123.202? ( [195.241.221.201]) by mx.google.com with ESMTP id e34sm6926576ugd.2007.01.22.06.16.02; Mon, 22 Jan 2007 06:16:03 -0800 (PST) Message-ID: <45B4C71B.1030408@gmail.com> Date: Mon, 22 Jan 2007 15:15:55 +0100 From: Rene Ladan User-Agent: Thunderbird 1.5.0.9 (X11/20070119) MIME-Version: 1.0 To: fs@freebsd.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: unused code in msdosfs_lookup.c ? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 14:43:22 -0000 Hi, while working on the XTAF fs module (see the archives), I discovered that the code path in the lookup() routine which deals with cnp->cn_nameptr being "." or ".." is never used. To verify this, I added a printf() to the analogous code in sys/fs/msdosfs/msdosfs_lookup.c (lines 134-145, revision 1.47), but the following commands could not trigger the code: % ls . % ls .. % file . % file ../. % hd . % hd .. % cd .. % cd ../a/b % ls -laoT . % du /mountpoint This code fakes the "." and ".." entries in the root directory of msdos filesystems, which are otherwise absent. So it seems like that code was either never tested or something in the calling code changed (which would be cachedlookup() in VOP layer). Ideas? Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-fs@FreeBSD.ORG Mon Jan 22 15:39:55 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13B3216A404 for ; Mon, 22 Jan 2007 15:39:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by mx1.freebsd.org (Postfix) with ESMTP id AE9E713C471 for ; Mon, 22 Jan 2007 15:39:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.227] (helo=fw.zoral.com.ua) by relay01.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1H90bt-0002Mp-G3 for fs@freebsd.org; Mon, 22 Jan 2007 16:57:34 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id l0MEvICJ064312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jan 2007 16:57:18 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id l0MEvIo4035291; Mon, 22 Jan 2007 16:57:18 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id l0MEvI4q035290; Mon, 22 Jan 2007 16:57:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 22 Jan 2007 16:57:18 +0200 From: Kostik Belousov To: Rene Ladan Message-ID: <20070122145718.GC71333@deviant.kiev.zoral.com.ua> References: <45B4C71B.1030408@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/e2eDi0V/xtL+Mc8" Content-Disposition: inline In-Reply-To: <45B4C71B.1030408@gmail.com> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=ALL_TRUSTED,SPF_NEUTRAL autolearn=failed version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on fw.zoral.com.ua X-Scanner-Signature: d3dfc5a0b247ea81d48b6a940fe6235f X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 701 [Jan 22 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: fs@freebsd.org Subject: Re: unused code in msdosfs_lookup.c ? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 15:39:55 -0000 --/e2eDi0V/xtL+Mc8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 22, 2007 at 03:15:55PM +0100, Rene Ladan wrote: > Hi, >=20 > while working on the XTAF fs module (see the archives), I discovered > that the code path in the lookup() routine which deals with > cnp->cn_nameptr being "." or ".." is never used. >=20 > To verify this, I added a printf() to the analogous code in > sys/fs/msdosfs/msdosfs_lookup.c (lines 134-145, revision 1.47), but the > following commands could not trigger the code: >=20 > % ls . > % ls .. > % file . > % file ../. > % hd . > % hd .. > % cd .. > % cd ../a/b > % ls -laoT . > % du /mountpoint >=20 > This code fakes the "." and ".." entries in the root directory of msdos > filesystems, which are otherwise absent. >=20 > So it seems like that code was either never tested or something in the > calling code changed (which would be cachedlookup() in VOP layer). >=20 > Ideas? See, for instance, kern/92785. --/e2eDi0V/xtL+Mc8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFtNDNC3+MBN1Mb4gRApCbAKC4adIYJSoAf3c+WNZXy6Nvns/wFQCfbbja RVBG/BIWGprZS3wOBgH8IyE= =U64V -----END PGP SIGNATURE----- --/e2eDi0V/xtL+Mc8-- From owner-freebsd-fs@FreeBSD.ORG Mon Jan 22 16:22:23 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 71D7016A406 for ; Mon, 22 Jan 2007 16:22:23 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id 06A4F13C459 for ; Mon, 22 Jan 2007 16:22:22 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by nf-out-0910.google.com with SMTP id m19so517492nfc for ; Mon, 22 Jan 2007 08:22:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=A4oxXEQUB4TKrZQ2O+boFeEP2Fnsejfm5BTr4tWentXxJPj3nyxXqDjwEBvzMDNUdroBb3UnWit1kPsOzGzeFTI23KSW+6mjtW45a2usDFcYtH/u20V4yRYkRqsIg/rHkrzWkw95YnCmaJUUwc36GjlH/qQ31aALuuJ0TxaohK8= Received: by 10.48.14.4 with SMTP id 4mr6914876nfn.1169482940472; Mon, 22 Jan 2007 08:22:20 -0800 (PST) Received: from ?192.168.123.202? ( [195.241.221.201]) by mx.google.com with ESMTP id m15sm15681223nfc.2007.01.22.08.22.19; Mon, 22 Jan 2007 08:22:19 -0800 (PST) Message-ID: <45B4E4B3.9050206@gmail.com> Date: Mon, 22 Jan 2007 17:22:11 +0100 From: Rene Ladan User-Agent: Thunderbird 1.5.0.9 (X11/20070119) MIME-Version: 1.0 To: Kostik Belousov References: <45B4C71B.1030408@gmail.com> <20070122145718.GC71333@deviant.kiev.zoral.com.ua> In-Reply-To: <20070122145718.GC71333@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: fs@freebsd.org Subject: Re: unused code in msdosfs_lookup.c ? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2007 16:22:23 -0000 Kostik Belousov schreef: > On Mon, Jan 22, 2007 at 03:15:55PM +0100, Rene Ladan wrote: >> Hi, >> >> while working on the XTAF fs module (see the archives), I discovered >> that the code path in the lookup() routine which deals with >> cnp->cn_nameptr being "." or ".." is never used. >> >> To verify this, I added a printf() to the analogous code in >> sys/fs/msdosfs/msdosfs_lookup.c (lines 134-145, revision 1.47), >> This code fakes the "." and ".." entries in the root directory of msdos >> filesystems, which are otherwise absent. [..] >> >> So it seems like that code was either never tested or something in the >> calling code changed (which would be cachedlookup() in VOP layer). >> >> Ideas? > > See, for instance, kern/92785. Good reading, it teached me that that code is for the absolute root directory, not for the root directory of the msdos filesystem. That is one reason why it is never used, because (according to the pr) the vfs layer already handles this case. Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-fs@FreeBSD.ORG Tue Jan 23 10:44:18 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F49516A400 for ; Tue, 23 Jan 2007 10:44:18 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id D9E2E13C4D0 for ; Tue, 23 Jan 2007 10:44:17 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so563460ana for ; Tue, 23 Jan 2007 02:44:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type; b=cMUitUx5MLOEnaRLbJ+IoiR0t7xCf3rpQ2EMfkpPQqHyzJAhc3gyEIR/aI/U32P9aYsshA42BhacIJwM9rmH0lWJt0FApEl898QfpTlb4HXDBHShluf61F1YlJ1YrJQ0tnR7g2V32k1uECVyaCbAb1ShFqY/vdCPP3C/cmVCatY= Received: by 10.78.134.12 with SMTP id h12mr243674hud.1169549051644; Tue, 23 Jan 2007 02:44:11 -0800 (PST) Received: from ?192.168.123.202? ( [195.241.221.201]) by mx.google.com with ESMTP id c18sm6040092hub.2007.01.23.02.44.10; Tue, 23 Jan 2007 02:44:10 -0800 (PST) Message-ID: <45B5E6F0.9040704@gmail.com> Date: Tue, 23 Jan 2007 11:44:00 +0100 From: Rene Ladan User-Agent: Thunderbird 1.5.0.9 (X11/20070119) MIME-Version: 1.0 To: fs@freebsd.org References: <45B4CC81.1090607@gmail.com> In-Reply-To: <45B4CC81.1090607@gmail.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/mixed; boundary="------------030006070907030103030700" Cc: Subject: Re: xtaf-20070122 available X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 10:44:18 -0000 This is a multi-part message in MIME format. --------------030006070907030103030700 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Rene Ladan schreef: > Hi, > > I put a new version of the XTAF (xbox360 fs) module online at > http://home.tiscali.nl/rladan/freebsd/xtaf/ > Todays version (xtaf-20070123) doesn't need a special mount binary anymore. The patch consists of two files (see below). [... bugs ...] These are still present. [... test image ...] > To test it on a CURRENT box : > As the userland patch has gone, this can be simplified to: (download, verify, and bunzip2 the files) # cd /usr/src # patch < glue-20070123.diff # patch < kern-20070123.diff # cd /sys/modules/xtaf # make depend && make obj && make && make install # kldload xtaf (get/verify part0.tbz, extract part0.xtaf from it) # mdconfig -a -t vnode -f part0.xtaf # mount -t xtaf /dev/mdX /your/favorite/mountpoint (play with it) > > Note that write support is currently disabled behind #ifdef XTAF_WRITE > NFS support is currently disabled behind #ifdef XTAF_NFS The original msdosfs NFS code is incomplete, it misses calls to VFS_CHECKEXP(9) which are necessary according to VFS_FHTOVP(9). The following extra mount options are available using -o : uid=n : set the owner, defaults to 0 (root) gid=n : set the group, defaults to 0 (wheel) mask=o : set the octal file mask, defaults to 644 dirmask=o : set the octal dir mask, defaults to 755 > Regards, > Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 --------------030006070907030103030700 Content-Type: text/plain; name="xtaf-20070123.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xtaf-20070123.txt" -rw-r--r-- 1 rene wheel 702 Jan 23 11:12 glue-20070123.diff.bz2 MD5 (glue-20070123.diff.bz2) = 16887db3711dd90c85630bb51fb15549 SHA256 (glue-20070123.diff.bz2) = 42717e7802b4ffcfd3c3bb91e0653979ca671baf1970ea23137fbc6191e0f9ac -rw-r--r-- 1 rene wheel 36130 Jan 23 11:12 kern-20070123.diff.bz2 MD5 (kern-20070123.diff.bz2) = 4667a4d2c878e458cfcaca58aafdbc3b SHA256 (kern-20070123.diff.bz2) = ff0762ea9fed3ad6f95dc8c596717ddcc06403ce212cd5a550fc81bf495099cb --------------030006070907030103030700 Content-Type: text/plain; name="part0-csum.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="part0-csum.txt" -rw-r--r-- 1 rene rene 1219821 Jan 22 14:53 part0.tbz MD5 (part0.tbz) = 7ebd3573cfaafbfeb198341a302b298b SHA256 (part0.tbz) = 0fb54dda3a79eb9c4f81f834ca8b378d5e3eb283f6381862ca33c2c4c8b8943d --------------030006070907030103030700-- From owner-freebsd-fs@FreeBSD.ORG Tue Jan 23 13:18:41 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4A9A16A402; Tue, 23 Jan 2007 13:18:41 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id 9DE1C13C469; Tue, 23 Jan 2007 13:18:41 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id D164E6E32D; Wed, 24 Jan 2007 00:18:37 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 41E6B8C0A; Wed, 24 Jan 2007 00:18:39 +1100 (EST) Date: Wed, 24 Jan 2007 00:18:38 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: fs@freebsd.org, kib@freebsd.org Message-ID: <20070123233124.R33734@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: more lost dotdot caching pessimizes nfs especially X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 13:18:41 -0000 I suspect that recent locking fixes near dotdot are responsible for slowing down builds over nfs even further by increasing the number of RPCs. Times and RPC counts for building a RELENG_4 kernel under -current on a Turion X2 2GHz: With i386 SMP kernel built a few days ago: %%% make depend: 9.31 real 5.04 user 1.25 sys Lookup Read Write Access Getattr Other Total 1269 541 591 20633 447 112 23593 make: 67.28 real 55.55 user 3.86 sys Lookup Read Write Create Access Fsstat Other Total 4633 2370 5291 436 22269 1726 14 36739 %%% With i386 SMP kernel built an hour ago: %%% make depend: 13.70 real 5.38 user 1.56 sys Lookup Read Write Access Getattr Other Total 14008 541 591 38615 447 96 54298 make: 71.49 real 55.21 user 4.45 sys Lookup Read Write Create Access Fsstat Other Total 19237 2370 5292 436 41860 1714 14 70923 %%% Note that only the number of Lookups and Access's changed significantly (Access goes with Lookup). This is without -j4 so that the slowdown is more obvious. "make depend" is not parallelized, so -j4 has little effect for it, but -j4 now speeds "make" up by even more than a factor of 2 by running more RPCs in parallel. The speedup used to be only from 67.3 to 34.3 seconds, but now it is from 71.5 to 34.8 seconds. This is with my old fixes and hacks to reduce RPCs, and the network tuned for latency (80 usec ping -f latency). Plain -current would use about 120000 RPCs for "make" and thus take 10-20 seconds longer. It would use a bit less than that for "make depend" and thus take 5-10 seconds longer. "make depend" would take about twice as long as it should. It can easily take much longer than that on machines with larger network latency. Bruce From owner-freebsd-fs@FreeBSD.ORG Tue Jan 23 13:39:36 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 281EA16A403 for ; Tue, 23 Jan 2007 13:39:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id B588513C469 for ; Tue, 23 Jan 2007 13:39:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.227] (helo=fw.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1H9Lry-000F5d-CA for fs@freebsd.org; Tue, 23 Jan 2007 15:39:35 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id l0NDdLpj001494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jan 2007 15:39:22 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id l0NDdLHo091733; Tue, 23 Jan 2007 15:39:21 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id l0NDdL4L091732; Tue, 23 Jan 2007 15:39:21 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 23 Jan 2007 15:39:21 +0200 From: Kostik Belousov To: Bruce Evans Message-ID: <20070123133921.GL71333@deviant.kiev.zoral.com.ua> References: <20070123233124.R33734@delplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="00hq2S6J2Jlg6EbK" Content-Disposition: inline In-Reply-To: <20070123233124.R33734@delplex.bde.org> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=ALL_TRUSTED,SPF_NEUTRAL autolearn=failed version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on fw.zoral.com.ua X-Scanner-Signature: b11a0dd960b728cbee92fea3b4ac1d10 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 702 [Jan 23 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: fs@freebsd.org Subject: Re: more lost dotdot caching pessimizes nfs especially X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 13:39:36 -0000 --00hq2S6J2Jlg6EbK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 24, 2007 at 12:18:38AM +1100, Bruce Evans wrote: > I suspect that recent locking fixes near dotdot are responsible for > slowing down builds over nfs even further by increasing the number > of RPCs. Times and RPC counts for building a RELENG_4 kernel under > -current on a Turion X2 2GHz: >=20 > With i386 SMP kernel built a few days ago: > %%% > make depend: > 9.31 real 5.04 user 1.25 sys > Lookup Read Write Access Getattr Other Total > 1269 541 591 20633 447 112 23593 >=20 > make: > 67.28 real 55.55 user 3.86 sys > Lookup Read Write Create Access Fsstat Other Total > 4633 2370 5291 436 22269 1726 14 36739 > %%% >=20 > With i386 SMP kernel built an hour ago: > %%% > make depend: > 13.70 real 5.38 user 1.56 sys > Lookup Read Write Access Getattr Other Total > 14008 541 591 38615 447 96 54298 >=20 > make: > 71.49 real 55.21 user 4.45 sys > Lookup Read Write Create Access Fsstat Other Total > 19237 2370 5292 436 41860 1714 14 70923 > %%% >=20 > Note that only the number of Lookups and Access's changed significantly > (Access goes with Lookup). >=20 > This is without -j4 so that the slowdown is more obvious. "make depend" > is not parallelized, so -j4 has little effect for it, but -j4 now > speeds "make" up by even more than a factor of 2 by running more RPCs > in parallel. The speedup used to be only from 67.3 to 34.3 seconds, > but now it is from 71.5 to 34.8 seconds. >=20 > This is with my old fixes and hacks to reduce RPCs, and the network > tuned for latency (80 usec ping -f latency). Plain -current would use > about 120000 RPCs for "make" and thus take 10-20 seconds longer. It > would use a bit less than that for "make depend" and thus take 5-10 > seconds longer. "make depend" would take about twice as long as it > should. It can easily take much longer than that on machines with > larger network latency. >=20 Bruce, could you confirm that reversal of rev. 1.97 of vfs_lookup.c would restore the old Lookup/Access RPC statistic ? --00hq2S6J2Jlg6EbK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFthAIC3+MBN1Mb4gRAoWUAJ4xsM5HPX5bb1X851EzriXU5x0esQCfRq/j PkM7zaWmF1JToNwfcvT02R0= =kyxA -----END PGP SIGNATURE----- --00hq2S6J2Jlg6EbK-- From owner-freebsd-fs@FreeBSD.ORG Tue Jan 23 13:59:46 2007 Return-Path: X-Original-To: fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 049EB16A400 for ; Tue, 23 Jan 2007 13:59:46 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id C0AB013C467 for ; Tue, 23 Jan 2007 13:59:45 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id F0B846E0C1; Wed, 24 Jan 2007 00:59:41 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 80D7B27405; Wed, 24 Jan 2007 00:59:43 +1100 (EST) Date: Wed, 24 Jan 2007 00:59:42 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kostik Belousov In-Reply-To: <20070123133921.GL71333@deviant.kiev.zoral.com.ua> Message-ID: <20070124005135.J14386@besplex.bde.org> References: <20070123233124.R33734@delplex.bde.org> <20070123133921.GL71333@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: fs@FreeBSD.org Subject: Re: more lost dotdot caching pessimizes nfs especially X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2007 13:59:46 -0000 On Tue, 23 Jan 2007, Kostik Belousov wrote: > On Wed, Jan 24, 2007 at 12:18:38AM +1100, Bruce Evans wrote: >> I suspect that recent locking fixes near dotdot are responsible for >> slowing down builds over nfs even further by increasing the number >> of RPCs. Times and RPC counts for building a RELENG_4 kernel under >> -current on a Turion X2 2GHz: Nevermind, it was an editing error that lost all the non-hack part of my RPC reductions. This lost about half of them. > could you confirm that reversal of rev. 1.97 of vfs_lookup.c would restore > the old Lookup/Access RPC statistic ? Thanks for the quick reply. I tried that first. It had no effect. While you are here I'll ask for a non-hack to restore caching of dotdot :-). (I just back out rev.1.103 of vfs_cache.c). Bruce From owner-freebsd-fs@FreeBSD.ORG Sat Jan 27 22:47:55 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1473416A401; Sat, 27 Jan 2007 22:47:55 +0000 (UTC) (envelope-from joe@tao.org.uk) Received: from mailhost.tao.org.uk (transwarp.tao.org.uk [87.74.4.34]) by mx1.freebsd.org (Postfix) with ESMTP id 5D91613C48D; Sat, 27 Jan 2007 22:47:53 +0000 (UTC) (envelope-from joe@tao.org.uk) Received: from genius.tao.org.uk (wireless58.dhcp.tao.org.uk [87.74.4.58]) by mailhost.tao.org.uk (Postfix) with ESMTP id 9DCFD5E98; Sat, 27 Jan 2007 22:47:51 +0000 (GMT) Received: by genius.tao.org.uk (Postfix, from userid 1000) id 6EF7140A8; Sat, 27 Jan 2007 22:47:49 +0000 (GMT) Date: Sat, 27 Jan 2007 22:47:49 +0000 From: Josef Karthauser To: Joe Koberg Message-ID: <20070127224749.GA8203@genius.tao.org.uk> Mail-Followup-To: Josef Karthauser , Joe Koberg , stable@freebsd.org, fs@freebsd.org References: <20070115112106.GA2304@genius.tao.org.uk> <20070115115650.GB2304@genius.tao.org.uk> <45AB9BE4.1030606@osoft.us> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i0/AhcQY5QxfSsSZ" Content-Disposition: inline In-Reply-To: <45AB9BE4.1030606@osoft.us> User-Agent: Mutt/1.5.11 Cc: stable@freebsd.org, fs@freebsd.org Subject: mpt problems. (Re: Dell hardware raid 0 (sas5ir) or gmirror?) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 22:47:55 -0000 --i0/AhcQY5QxfSsSZ Content-Type: multipart/mixed; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 15, 2007 at 09:21:08AM -0600, Joe Koberg wrote: >=20 > I just bought two Dell PE-1950's to use as routers. They have LSI Logic= =20 > PERC/5i's attached to 80GB SATA drives. I am pretty sure this is the=20 > same card used for SAS. >=20 > One thing is for sure, the mfi(4) card and driver aren't shy! See below= =20 > for examples of the kernel messages I get regularly. I am sure drive=20 > failure would be well noted. >=20 > As to rebuilding on-line, I suspect a drive (hot-)swap will initiate the= =20 > rebuild. There is a CLI tool (megarc) in ports/sysutils/megarc but I=20 > haven't tried to use it yet. >=20 > All in all I would recommend the PERC/5i. >=20 So I've just picked up a Dell PE-860, with the SAS card. However it doesn't appear to be an mfi(4) card, instead it's an mpt(4) card. And, it doesn't appear to work properly; at least something isn't quite right. I've installed 6.2 on the box, and I'm attempting to create a gmirror with both of the disks attached to the mpt. I've created the filesystem on one of the disks ok (gmirror boot0 on da1s1), and then I attempt to insert the second disk (da0s1). The problem is that the synchronisation appears to progress ok, but when I add some additional load, like cvsuping the ports collection at the same time, after a short period I get loads of errors from the mpt controller and then geom disconnects the drive (da0s1). Wierdly when I reboot the machine the mpt controller refuses to probe da0, and I have to physically power cycle the machine before it sees the drive again. The error messages from mpt are attached in the file called 'messages'. The kernel probe boot time log is attached as dmesg.log. I hope there's a simple fix; I was hoping to commission this machine at the end of this coming week!!!! Joe --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=messages Jan 27 18:42:03 littoralis kernel: mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x01 Depth 121 Jan 27 18:44:01 littoralis kernel: mpt0: QUEUE FULL EVENT: Bus 0x00 Target 0x00 Depth 121 Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756328:48785 timed out for ccb 0xca8f0c00 (req->ccb 0xca8f0c00) Jan 27 18:51:06 littoralis kernel: mpt0: attempting to abort req 0xca756328:48785 function 0 Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755c28:48786 timed out for ccb 0xcc213800 (req->ccb 0xcc213800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758078:48787 timed out for ccb 0xca743000 (req->ccb 0xca743000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758468:48793 timed out for ccb 0xca8ee800 (req->ccb 0xca8ee800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755ec8:48795 timed out for ccb 0xcc214800 (req->ccb 0xcc214800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7527e0:48797 timed out for ccb 0xca8f2000 (req->ccb 0xca8f2000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7552f8:48801 timed out for ccb 0xca75a000 (req->ccb 0xca75a000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758af8:48803 timed out for ccb 0xca773c00 (req->ccb 0xca773c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752620:48805 timed out for ccb 0xca8e1400 (req->ccb 0xca8e1400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755218:48807 timed out for ccb 0xca8e1000 (req->ccb 0xca8e1000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752850:48809 timed out for ccb 0xca8e3800 (req->ccb 0xca8e3800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752f88:48811 timed out for ccb 0xca914400 (req->ccb 0xca914400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757c50:48813 timed out for ccb 0xca749000 (req->ccb 0xca749000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca753b58:48815 timed out for ccb 0xca8e7c00 (req->ccb 0xca8e7c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757780:48817 timed out for ccb 0xca672c00 (req->ccb 0xca672c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca754b50:48819 timed out for ccb 0xcc211800 (req->ccb 0xcc211800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7554b8:48821 timed out for ccb 0xca744400 (req->ccb 0xca744400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca753688:48823 timed out for ccb 0xca749800 (req->ccb 0xca749800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca753880:48825 timed out for ccb 0xca771400 (req->ccb 0xca771400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756fd8:48827 timed out for ccb 0xcc208400 (req->ccb 0xcc208400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca754a00:48829 timed out for ccb 0xca774800 (req->ccb 0xca774800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7527a8:48831 timed out for ccb 0xca907c00 (req->ccb 0xca907c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756ad0:48833 timed out for ccb 0xcc219c00 (req->ccb 0xcc219c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca754f40:48835 timed out for ccb 0xca915000 (req->ccb 0xca915000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758d28:48837 timed out for ccb 0xca90fc00 (req->ccb 0xca90fc00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757b38:48839 timed out for ccb 0xcc216800 (req->ccb 0xcc216800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7553d8:48841 timed out for ccb 0xca910800 (req->ccb 0xca910800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757a58:48843 timed out for ccb 0xca774c00 (req->ccb 0xca774c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752f50:48845 timed out for ccb 0xcc20f000 (req->ccb 0xcc20f000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758cb8:48847 timed out for ccb 0xca910000 (req->ccb 0xca910000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7568d8:48849 timed out for ccb 0xcc21d000 (req->ccb 0xcc21d000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757e48:48851 timed out for ccb 0xca8da800 (req->ccb 0xca8da800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7563d0:48853 timed out for ccb 0xcc214400 (req->ccb 0xcc214400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757c18:48855 timed out for ccb 0xca8e4c00 (req->ccb 0xca8e4c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca754958:48857 timed out for ccb 0xca917400 (req->ccb 0xca917400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755480:48859 timed out for ccb 0xca74a800 (req->ccb 0xca74a800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757ac8:48861 timed out for ccb 0xcc216c00 (req->ccb 0xcc216c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7569f0:48863 timed out for ccb 0xca904400 (req->ccb 0xca904400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757978:48865 timed out for ccb 0xca75a800 (req->ccb 0xca75a800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca754b18:48867 timed out for ccb 0xcc20c400 (req->ccb 0xcc20c400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758740:48869 timed out for ccb 0xcc222800 (req->ccb 0xcc222800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7538f0:48871 timed out for ccb 0xca8dc000 (req->ccb 0xca8dc000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752ff8:48873 timed out for ccb 0xca762000 (req->ccb 0xca762000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7562b8:48875 timed out for ccb 0xca761c00 (req->ccb 0xca761c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758970:48877 timed out for ccb 0xca8f7800 (req->ccb 0xca8f7800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758820:48879 timed out for ccb 0xca908800 (req->ccb 0xca908800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757be0:48881 timed out for ccb 0xca905400 (req->ccb 0xca905400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca753500:48883 timed out for ccb 0xcc21c400 (req->ccb 0xcc21c400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752d90:48885 timed out for ccb 0xcc212400 (req->ccb 0xcc212400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757a20:48887 timed out for ccb 0xca8ef000 (req->ccb 0xca8ef000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756670:48889 timed out for ccb 0xca75b800 (req->ccb 0xca75b800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7551a8:48891 timed out for ccb 0xcc218800 (req->ccb 0xcc218800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758318:48893 timed out for ccb 0xca905000 (req->ccb 0xca905000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757908:48895 timed out for ccb 0xca74a400 (req->ccb 0xca74a400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752930:48897 timed out for ccb 0xca917c00 (req->ccb 0xca917c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757b70:48899 timed out for ccb 0xcc211c00 (req->ccb 0xcc211c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7528c0:48901 timed out for ccb 0xca743c00 (req->ccb 0xca743c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755988:48903 timed out for ccb 0xcc211400 (req->ccb 0xcc211400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758e08:48905 timed out for ccb 0xcc20ac00 (req->ccb 0xcc20ac00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757470:48907 timed out for ccb 0xca8ef400 (req->ccb 0xca8ef400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752e70:48909 timed out for ccb 0xcc21c000 (req->ccb 0xcc21c000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756520:48911 timed out for ccb 0xcc218000 (req->ccb 0xcc218000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757940:48913 timed out for ccb 0xcc20ec00 (req->ccb 0xcc20ec00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755058:48915 timed out for ccb 0xca794c00 (req->ccb 0xca794c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758eb0:48917 timed out for ccb 0xca776c00 (req->ccb 0xca776c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7542c8:48919 timed out for ccb 0xca8ebc00 (req->ccb 0xca8ebc00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7570b8:48921 timed out for ccb 0xcc215800 (req->ccb 0xcc215800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7587e8:48923 timed out for ccb 0xca8dd800 (req->ccb 0xca8dd800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7556b0:48925 timed out for ccb 0xca775400 (req->ccb 0xca775400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7533e8:48927 timed out for ccb 0xca773000 (req->ccb 0xca773000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7553a0:48929 timed out for ccb 0xca740800 (req->ccb 0xca740800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752fc0:48931 timed out for ccb 0xcc212000 (req->ccb 0xcc212000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755d78:48933 timed out for ccb 0xca76f800 (req->ccb 0xca76f800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca753148:48935 timed out for ccb 0xca744000 (req->ccb 0xca744000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755b10:48937 timed out for ccb 0xca793800 (req->ccb 0xca793800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7572e8:48939 timed out for ccb 0xca673400 (req->ccb 0xca673400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca754300:48941 timed out for ccb 0xca776000 (req->ccb 0xca776000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756a60:48943 timed out for ccb 0xca770000 (req->ccb 0xca770000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752348:48945 timed out for ccb 0xca8edc00 (req->ccb 0xca8edc00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca753810:48947 timed out for ccb 0xca73f000 (req->ccb 0xca73f000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca754c30:48949 timed out for ccb 0xca909400 (req->ccb 0xca909400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7544f8:48951 timed out for ccb 0xca762400 (req->ccb 0xca762400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca754098:48953 timed out for ccb 0xca915800 (req->ccb 0xca915800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7584d8:48955 timed out for ccb 0xcc209c00 (req->ccb 0xcc209c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca754028:48957 timed out for ccb 0xca761400 (req->ccb 0xca761400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7538b8:48959 timed out for ccb 0xca76f400 (req->ccb 0xca76f400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752230:48961 timed out for ccb 0xca8f2c00 (req->ccb 0xca8f2c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7581c8:48963 timed out for ccb 0xcc20d400 (req->ccb 0xcc20d400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7523b8:48965 timed out for ccb 0xcc209000 (req->ccb 0xcc209000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755100:48967 timed out for ccb 0xca73f400 (req->ccb 0xca73f400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7543a8:48969 timed out for ccb 0xcc215000 (req->ccb 0xcc215000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca754cd8:48971 timed out for ccb 0xca75b000 (req->ccb 0xca75b000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca753d88:48973 timed out for ccb 0xcc21c800 (req->ccb 0xcc21c800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755fa8:48975 timed out for ccb 0xca8db800 (req->ccb 0xca8db800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755f70:48977 timed out for ccb 0xca75b400 (req->ccb 0xca75b400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca753378:48979 timed out for ccb 0xca903800 (req->ccb 0xca903800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7535e0:48981 timed out for ccb 0xca8f8400 (req->ccb 0xca8f8400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758270:48983 timed out for ccb 0xcc215c00 (req->ccb 0xcc215c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752658:48985 timed out for ccb 0xca8f1800 (req->ccb 0xca8f1800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7523f0:48987 timed out for ccb 0xca916000 (req->ccb 0xca916000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7567c0:48989 timed out for ccb 0xca773800 (req->ccb 0xca773800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757e10:48991 timed out for ccb 0xca771000 (req->ccb 0xca771000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756be8:48993 timed out for ccb 0xca8ed400 (req->ccb 0xca8ed400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755790:48995 timed out for ccb 0xcc20f800 (req->ccb 0xcc20f800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7522a0:48997 timed out for ccb 0xca908c00 (req->ccb 0xca908c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752770:48999 timed out for ccb 0xca8e5400 (req->ccb 0xca8e5400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757390:49001 timed out for ccb 0xca75ac00 (req->ccb 0xca75ac00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7582e0:49003 timed out for ccb 0xca8f6000 (req->ccb 0xca8f6000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756638:49005 timed out for ccb 0xca8e8400 (req->ccb 0xca8e8400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755448:49007 timed out for ccb 0xca8f0800 (req->ccb 0xca8f0800) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca752a48:49009 timed out for ccb 0xca8dcc00 (req->ccb 0xca8dcc00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755e58:49011 timed out for ccb 0xca8dc400 (req->ccb 0xca8dc400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7564e8:49013 timed out for ccb 0xca784c00 (req->ccb 0xca784c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758a50:49015 timed out for ccb 0xca914000 (req->ccb 0xca914000) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756830:49017 timed out for ccb 0xcc213c00 (req->ccb 0xcc213c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca758890:49019 timed out for ccb 0xca785400 (req->ccb 0xca785400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca7535a8:49021 timed out for ccb 0xcc213400 (req->ccb 0xcc213400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca757208:49025 timed out for ccb 0xca759400 (req->ccb 0xca759400) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756f30:49027 timed out for ccb 0xca916c00 (req->ccb 0xca916c00) Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca753fb8:49029 timed out for ccb 0xcc222c00 (req->ccb 0xcc222c00) Jan 27 18:51:21 littoralis kernel: mpt0: mpt_wait_req(1) timed out Jan 27 18:51:21 littoralis kernel: mpt0: mpt_recover_commands: abort timed-out. Resetting controller Jan 27 18:51:21 littoralis kernel: mpt0: mpt_cam_event: 0x74 Jan 27 18:51:21 littoralis kernel: mpt0: Unhandled Event Notify Frame. Event 0xead5cc74 (ACK not required). Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca756328:48785 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755c28:48786 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758078:48787 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758468:48793 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755ec8:48795 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7527e0:48797 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7552f8:48801 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758af8:48803 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752620:48805 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755218:48807 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752850:48809 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752f88:48811 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757c50:48813 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca753b58:48815 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757780:48817 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca754b50:48819 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7554b8:48821 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca753688:48823 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca753880:48825 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca756fd8:48827 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca754a00:48829 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7527a8:48831 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca756ad0:48833 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca754f40:48835 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758d28:48837 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757b38:48839 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7553d8:48841 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757a58:48843 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752f50:48845 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758cb8:48847 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7568d8:48849 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757e48:48851 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7563d0:48853 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757c18:48855 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca754958:48857 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755480:48859 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757ac8:48861 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7569f0:48863 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757978:48865 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca754b18:48867 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758740:48869 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7538f0:48871 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752ff8:48873 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7562b8:48875 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758970:48877 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758820:48879 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757be0:48881 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca753500:48883 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752d90:48885 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757a20:48887 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca756670:48889 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7551a8:48891 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758318:48893 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757908:48895 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752930:48897 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757b70:48899 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7528c0:48901 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755988:48903 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758e08:48905 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757470:48907 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752e70:48909 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca756520:48911 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757940:48913 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755058:48915 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758eb0:48917 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7542c8:48919 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7570b8:48921 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7587e8:48923 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7556b0:48925 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7533e8:48927 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7553a0:48929 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752fc0:48931 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755d78:48933 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca753148:48935 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755b10:48937 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7572e8:48939 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca754300:48941 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca756a60:48943 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752348:48945 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca753810:48947 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca754c30:48949 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7544f8:48951 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca754098:48953 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7584d8:48955 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca754028:48957 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7538b8:48959 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752230:48961 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7581c8:48963 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7523b8:48965 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755100:48967 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7543a8:48969 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca754cd8:48971 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca753d88:48973 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755fa8:48975 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755f70:48977 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca753378:48979 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7535e0:48981 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758270:48983 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752658:48985 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7523f0:48987 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7567c0:48989 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757e10:48991 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca756be8:48993 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755790:48995 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7522a0:48997 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752770:48999 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757390:49001 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7582e0:49003 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca756638:49005 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755448:49007 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca752a48:49009 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca755e58:49011 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7564e8:49013 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758a50:49015 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca756830:49017 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca758890:49019 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca7535a8:49021 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca757208:49025 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca756f30:49027 Jan 27 18:51:21 littoralis kernel: mpt0: completing timedout/aborted req 0xca753fb8:49029 Jan 27 18:51:21 littoralis kernel: mpt0: mpt_cam_event: 0x16 Jan 27 18:51:21 littoralis kernel: mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required). Jan 27 18:51:21 littoralis kernel: mpt0: mpt_cam_event: 0x12 Jan 27 18:51:21 littoralis kernel: mpt0: Unhandled Event Notify Frame. Event 0x12 (ACK not required). Jan 27 18:51:21 littoralis kernel: mpt0: mpt_cam_event: 0x12 Jan 27 18:51:21 littoralis kernel: mpt0: Unhandled Event Notify Frame. Event 0x12 (ACK not required). Jan 27 18:51:21 littoralis kernel: mpt0: mpt_cam_event: 0x16 Jan 27 18:51:21 littoralis kernel: mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required). Jan 27 18:51:21 littoralis kernel: mpt0: mpt_cam_event: 0x16 Jan 27 18:51:21 littoralis kernel: mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required). Jan 27 18:51:21 littoralis kernel: mpt0: mpt_cam_event: 0x12 Jan 27 18:51:21 littoralis kernel: mpt0: Unhandled Event Notify Frame. Event 0x12 (ACK not required). Jan 27 18:51:21 littoralis kernel: mpt0: mpt_cam_event: 0x16 Jan 27 18:51:21 littoralis kernel: mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required). Jan 27 18:51:21 littoralis kernel: (da0:mpt0:0:0:0): lost device Jan 27 18:51:21 littoralis kernel: (da0:mpt0:0:0:0): Invalidating pack Jan 27 18:51:21 littoralis last message repeated 119 times Jan 27 18:51:21 littoralis kernel: GEOM_MIRROR: Device boot0: provider da0s1 disconnected. Jan 27 18:51:21 littoralis kernel: GEOM_MIRROR: Device boot0: rebuilding provider da0s1 stopped. Jan 27 18:51:21 littoralis kernel: (da0:mpt0:0:0:0): Synchronize cache failed, status == 0x4a, scsi status == 0x0 Jan 27 18:51:21 littoralis kernel: (da0:mpt0:0:0:0): removing device entry --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Description: dmesg.log Content-Disposition: attachment; filename=q Content-Transfer-Encoding: quoted-printable Copyright (c) 1992-2007 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 6.2-STABLE #10: Sat Jan 27 20:19:48 GMT 2007 joe@littoralis.tao.org.uk:/usr/obj/usr/src/sys/LITTORALIS-SMP ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU X3220 @ 2.40GHz (2400.10-MHz 686-class= CPU) Origin =3D "GenuineIntel" Id =3D 0x6f7 Stepping =3D 7 Features=3D0xbfebfbff Features2=3D0xe3bd,CX16,,> AMD Features=3D0x20100000 AMD Features2=3D0x1 Cores per package: 4 real memory =3D 5368709120 (5120 MB) avail memory =3D 4185096192 (3991 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 4 ioapic1: Changing APIC ID to 5 ioapic1: WARNING: intbase 32 !=3D expected base 24 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 mpt0: port 0xec00-0xecff mem 0xdfdfc000-0xdfdff= fff,0xdfde0000-0xdfdeffff irq 16 at device 8.0 on pci2 mpt0: [GIANT-LOCKED] mpt0: MPI Version=3D1.5.12.0 mpt0: mpt_cam_event: 0x16 mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required). mpt0: mpt_cam_event: 0x12 mpt0: Unhandled Event Notify Frame. Event 0x12 (ACK not required). mpt0: mpt_cam_event: 0x12 mpt0: Unhandled Event Notify Frame. Event 0x12 (ACK not required). mpt0: mpt_cam_event: 0x16 mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required). pci1: at device 0.1 (no driver atta= ched) pcib3: at device 28.0 on pci0 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 pcib5: at device 2.0 on pci4 pci5: on pcib5 pci5: at device 2.0 (no driver attached) pci5: at device 4.0 (no driver attached) pci5: at device 4.1 (no driver attached) pci5: at device 4.2 (no driver attached) atapci0: port 0xd8f0-0xd8f7,0xd8e4-0xd8e7,0xd= 8d8-0xd8df,0xd8d0-0xd8d3,0xd870-0xd87f mem 0xdf9eec00-0xdf9eecff irq 32 at = device 7.0 on pci5 ata2: on atapci0 ata3: on atapci0 pcib6: at device 28.4 on pci0 pci6: on pcib6 bge0: mem 0xdf5f0000-0xdf5fffff irq= 16 at device 0.0 on pci6 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000b= aseTX-FDX, auto bge0: Ethernet address: 00:15:c5:fc:22:17 pcib7: at device 28.5 on pci0 pci7: on pcib7 bge1: mem 0xdf3f0000-0xdf3fffff irq= 17 at device 0.0 on pci7 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000b= aseTX-FDX, auto bge1: Ethernet address: 00:15:c5:fc:22:18 pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pci0: at device 29.7 (no driver attached) pcib8: at device 30.0 on pci0 pci8: on pcib8 isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177= ,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci1 ata1: on atapci1 pci0: at device 31.3 (no driver attached) fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acp= i0 sio0: type 16550A fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 orm0: at iomem 0xc0000-0xcafff,0xec000-0xeffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled,= default to accept, logging disabled acd0: CDRW at ata0-master UDMA33 device_attach: afd0 attach returned 6 acd1: CDROM at ata2-slave PIO3 da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device=20 da0: 300.000MB/s transfers, Tagged Queueing Enabled da0: 286102MB (585937500 512 byte sectors: 255H 63S/T 36472C) da1 at mpt0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-5 device=20 da1: 300.000MB/s transfers, Tagged Queueing Enabled da1: 286102MB (585937500 512 byte sectors: 255H 63S/T 36472C) SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! GEOM_MIRROR: Device boot0 created (id=3D1393958858). GEOM_MIRROR: Device boot0: provider da0s1 detected. GEOM_MIRROR: Device boot0: provider da1s1 detected. GEOM_MIRROR: Device boot0: provider da1s1 activated. GEOM_MIRROR: Device boot0: provider mirror/boot0 launched. GEOM_MIRROR: Device boot0: rebuilding provider da0s1. Trying to mount root from ufs:/dev/mirror/boot0a --NzB8fVQJ5HfG6fxh-- --i0/AhcQY5QxfSsSZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iEYEARECAAYFAkW71pQACgkQXVIcjOaxUBYfrwCdHI1lfDAa/G1L/h4KSQW2bIi5 BP0An1dDcr7fAQAcmbMseRxzPcvwmbgV =IidI -----END PGP SIGNATURE----- --i0/AhcQY5QxfSsSZ-- From owner-freebsd-fs@FreeBSD.ORG Sat Jan 27 23:48:19 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 753E516A400 for ; Sat, 27 Jan 2007 23:48:19 +0000 (UTC) (envelope-from wilbury@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239]) by mx1.freebsd.org (Postfix) with ESMTP id E8BFD13C521 for ; Sat, 27 Jan 2007 23:48:07 +0000 (UTC) (envelope-from wilbury@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so1191633wxc for ; Sat, 27 Jan 2007 15:48:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jbZd4xjBgX0Y1P0If+fRvBnBl5361dHO7voWA1eDvU6lphuubBm8ASS+HPFda/xT0TXSECFNR77EiMHK0LmUUDGVNxa/i0MMbeP/qwe6PWdG3gM8LAfAElefmuum4CUcFR5lp/sdrqWZab0nS+8fgpeQy3l+aCyn5uBl1RmOUwE= Received: by 10.70.35.1 with SMTP id i1mr9327137wxi.1169940057085; Sat, 27 Jan 2007 15:20:57 -0800 (PST) Received: by 10.70.40.11 with HTTP; Sat, 27 Jan 2007 15:20:56 -0800 (PST) Message-ID: Date: Sun, 28 Jan 2007 00:20:56 +0100 From: "Juraj Lutter" To: "Josef Karthauser" , "Joe Koberg" , stable@freebsd.org, fs@freebsd.org In-Reply-To: <20070127224749.GA8203@genius.tao.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070115112106.GA2304@genius.tao.org.uk> <20070115115650.GB2304@genius.tao.org.uk> <45AB9BE4.1030606@osoft.us> <20070127224749.GA8203@genius.tao.org.uk> Cc: Subject: Re: mpt problems. (Re: Dell hardware raid 0 (sas5ir) or gmirror?) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 23:48:19 -0000 On 1/27/07, Josef Karthauser wrote: > The problem is that the synchronisation appears to progress ok, but > when I add some additional load, like cvsuping the ports collection > at the same time, after a short period I get loads of errors from > the mpt controller and then geom disconnects the drive (da0s1). > Wierdly when I reboot the machine the mpt controller refuses to > probe da0, and I have to physically power cycle the machine before > it sees the drive again. I've been observing very similar behavriour with recent 6.2-STABLE on i386 with either Silicon Image 3114 or Promise FastTrak TX4. gmirror synchronisation worked OK until I've added some additional load on the synchronised volume. Unfortunately I haven't been able to take any reasonable DDB output :-( -- Sincerely yours, Juraj Lutter From owner-freebsd-fs@FreeBSD.ORG Sat Jan 27 23:49:15 2007 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8380C16A496 for ; Sat, 27 Jan 2007 23:49:15 +0000 (UTC) (envelope-from clay@milos.co.za) Received: from bart.milos.co.za (bart.milos.co.za [196.38.18.66]) by mx1.freebsd.org (Postfix) with ESMTP id 3E7BC13C4CB for ; Sat, 27 Jan 2007 23:49:13 +0000 (UTC) (envelope-from clay@milos.co.za) Received: (qmail 82865 invoked by uid 89); 27 Jan 2007 23:21:41 -0000 Received: from unknown (HELO claylaptop) (clay@milos.za.net@192.168.3.254) by bart.milos.co.za with ESMTPA; 27 Jan 2007 23:21:41 -0000 Message-ID: <058601c7426a$04728890$fe03a8c0@claylaptop> From: "Clayton Milos" To: "Josef Karthauser" References: <20070115112106.GA2304@genius.tao.org.uk><20070115115650.GB2304@genius.tao.org.uk><45AB9BE4.1030606@osoft.us> <20070127224749.GA8203@genius.tao.org.uk> Date: Sun, 28 Jan 2007 01:22:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Cc: stable@freebsd.org, fs@freebsd.org Subject: Re: mpt problems. (Re: Dell hardware raid 0 (sas5ir) or gmirror?) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 23:49:15 -0000 On Mon, Jan 15, 2007 at 09:21:08AM -0600, Joe Koberg wrote: > > I just bought two Dell PE-1950's to use as routers. They have LSI Logic > PERC/5i's attached to 80GB SATA drives. I am pretty sure this is the > same card used for SAS. > > One thing is for sure, the mfi(4) card and driver aren't shy! See below > for examples of the kernel messages I get regularly. I am sure drive > failure would be well noted. > > As to rebuilding on-line, I suspect a drive (hot-)swap will initiate the > rebuild. There is a CLI tool (megarc) in ports/sysutils/megarc but I > haven't tried to use it yet. > > All in all I would recommend the PERC/5i. > So I've just picked up a Dell PE-860, with the SAS card. However it doesn't appear to be an mfi(4) card, instead it's an mpt(4) card. And, it doesn't appear to work properly; at least something isn't quite right. I've installed 6.2 on the box, and I'm attempting to create a gmirror with both of the disks attached to the mpt. I've created the filesystem on one of the disks ok (gmirror boot0 on da1s1), and then I attempt to insert the second disk (da0s1). The problem is that the synchronisation appears to progress ok, but when I add some additional load, like cvsuping the ports collection at the same time, after a short period I get loads of errors from the mpt controller and then geom disconnects the drive (da0s1). Wierdly when I reboot the machine the mpt controller refuses to probe da0, and I have to physically power cycle the machine before it sees the drive again. The error messages from mpt are attached in the file called 'messages'. The kernel probe boot time log is attached as dmesg.log. I hope there's a simple fix; I was hoping to commission this machine at the end of this coming week!!!! Joe Hey Joe If you have to power cycle the box for it to work again I'd say the problem is more than likely hardware related and not something FreeBSD unless the driver for the card has the ability to disable the drive on the raid controller which I doubt. -Clay