From owner-freebsd-hardware@FreeBSD.ORG Sun Jul 23 00:53:51 2006 Return-Path: X-Original-To: freebsd-hardware@freebsd.org Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8745716A4DA for ; Sun, 23 Jul 2006 00:53:51 +0000 (UTC) (envelope-from scottd@cloud9.net) Received: from english-breakfast.cloud9.net (english-breakfast.cloud9.net [168.100.1.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B51143D45 for ; Sun, 23 Jul 2006 00:53:50 +0000 (GMT) (envelope-from scottd@cloud9.net) Received: from english-breakfast.cloud9.net (localhost.cloud9.net [127.0.0.1]) by english-breakfast.cloud9.net (Postfix) with SMTP id 6188517353 for ; Sat, 22 Jul 2006 20:53:50 -0400 (EDT) Received: from earl-grey.cloud9.net (earl-grey.cloud9.net [168.100.1.1]) by english-breakfast.cloud9.net (Postfix) with ESMTP id F415B1735E for ; Sat, 22 Jul 2006 20:53:49 -0400 (EDT) Date: Sat, 22 Jul 2006 20:53:49 -0400 (EDT) From: "scottd@cloud9.net" To: freebsd-hardware@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-AntiVirus: Checked by Vexira Antivirus v1.5 Subject: High-availability storage X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2006 00:53:51 -0000 Greetings, I'm looking for some information on high-availability direct-attached storage with FreeBSD. To be specific, some form of RAID 6 with 12 to 16 SATA drives (500 or 750GB). We have a 2TB NetApp filer, but will soon be outgrowing it. More NetApp space would be nice, but it's expensive and not as dense (144 or 300GB SCSI drives only) as other options. Given that FreeBSD now has snapshot support, and dual parity disk setups are more common than a few years ago, it's an attractive option. What's frustrating is that none of the external SATA controllers supported by FreeBSD (Areca 1120ML, Adaptec 4805) have more than 128MB of cache. Using SATA to Fibre Channel would be the next choice, with RAID 6 being handled by the array itself (Nexsan SATABoy, for example) but FC support on FreeBSD seems limited. Any thoughts? Thanks. - Scott From owner-freebsd-hardware@FreeBSD.ORG Sun Jul 23 05:18:00 2006 Return-Path: X-Original-To: freebsd-hardware@freebsd.org Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EE1116A4DA for ; Sun, 23 Jul 2006 05:18:00 +0000 (UTC) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id B17C243D46 for ; Sun, 23 Jul 2006 05:17:59 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.13.6/8.13.6) with ESMTP id k6N5HvgZ074241; Sat, 22 Jul 2006 23:17:57 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.13.6/8.13.6/Submit) id k6N5HuJx074240; Sat, 22 Jul 2006 23:17:56 -0600 (MDT) (envelope-from ken) Date: Sat, 22 Jul 2006 23:17:56 -0600 From: "Kenneth D. Merry" To: "scottd@cloud9.net" Message-ID: <20060723051756.GA73979@nargothrond.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-Virus-Scanned: ClamAV 0.88.1/1614/Fri Jul 21 14:27:38 2006 on nargothrond.kdm.org X-Virus-Status: Clean Cc: freebsd-hardware@freebsd.org Subject: Re: High-availability storage X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2006 05:18:00 -0000 On Sat, Jul 22, 2006 at 20:53:49 -0400, scottd@cloud9.net wrote: > > Greetings, > > I'm looking for some information on high-availability direct-attached > storage with FreeBSD. To be specific, some form of RAID 6 with 12 to 16 > SATA drives (500 or 750GB). > > We have a 2TB NetApp filer, but will soon be outgrowing it. More NetApp > space would be nice, but it's expensive and not as dense (144 or 300GB > SCSI drives only) as other options. Given that FreeBSD now has snapshot > support, and dual parity disk setups are more common than a few years ago, > it's an attractive option. > > What's frustrating is that none of the external SATA controllers supported > by FreeBSD (Areca 1120ML, Adaptec 4805) have more than 128MB of cache. > Using SATA to Fibre Channel would be the next choice, with RAID 6 being > handled by the array itself (Nexsan SATABoy, for example) but FC support > on FreeBSD seems limited. > > Any thoughts? Thanks. If all you need is 12-16 disks, you could just get a PC enclosure that can handle 15 or so drives, like the Supermicro SC933T. Then you can use internal SATA cabling. I've got an Areca ARC-1260, and it works fine. (It comes standard with 256MB cache, you can upgrade it to 1GB.) FreeBSD's FC support works fairly well, and should certainly work well enough to connect to a Nexsan box. QLogic and LSI boards both work fairly well. (I've used 2Gbit boards from both vendors.) Ken -- Kenneth Merry ken@kdm.org From owner-freebsd-hardware@FreeBSD.ORG Sun Jul 23 15:54:48 2006 Return-Path: X-Original-To: freebsd-hardware@freebsd.org Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E970416A4DF; Sun, 23 Jul 2006 15:54:48 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from schitzo.solgatos.com (pool-71-117-252-190.ptldor.fios.verizon.net [71.117.252.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BD3843D58; Sun, 23 Jul 2006 15:54:47 +0000 (GMT) (envelope-from freebsd@sopwith.solgatos.com) Received: from schitzo.solgatos.com (localhost.home.localnet [127.0.0.1]) by schitzo.solgatos.com (8.13.6/8.13.6) with ESMTP id k6NFskSV027679; Sun, 23 Jul 2006 08:54:46 -0700 Received: from sopwith.solgatos.com (uucp@localhost) by schitzo.solgatos.com (8.13.6/8.13.4/Submit) with UUCP id k6NFskw0027676; Sun, 23 Jul 2006 08:54:46 -0700 Received: from localhost by sopwith.solgatos.com (8.8.8/6.24) id PAA03098; Sun, 23 Jul 2006 15:53:48 GMT Message-Id: <200607231553.PAA03098@sopwith.solgatos.com> To: freebsd-hardware@freebsd.org, freebsd-multimedia@freebsd.org Date: Sun, 23 Jul 2006 08:53:48 +0100 From: Dieter Cc: Subject: Improving FreeBSD's hardware compatibility - TV tuners X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd@sopwith.solgatos.com List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2006 15:54:49 -0000 > analog TV? what's that? isn't everyone going digital? (yes, I know > that analog TV will be with us for a long time due to security cams > and other uses..) Broadcast analog TV will be going away soon. Yet there will be continue to be some uses for analog capture. So I recommend concentrating first on tuners that handle both analog and digital. Work is in progress on the Dvico Fusion5 tuners. The Fusion5 is nice because it is available in a USB version, which does not require a slot. Another tuner worthy of a BSD driver is the HD3000. Does both analog and digital in a variety of formats (NTSC, PAL, 8VSB, QAM, etc.) Has working Linux drivers with source. The only tuner I know of that is documented to be friendly to fair use rights. The Fusion5 and HD3000 use different chips. If one doesn't work well in a particular reception environment, the other might. From owner-freebsd-hardware@FreeBSD.ORG Mon Jul 24 06:58:05 2006 Return-Path: X-Original-To: freebsd-hardware@FreeBSD.org Delivered-To: freebsd-hardware@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1277116A4DD for ; Mon, 24 Jul 2006 06:58:05 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A15643D4C for ; Mon, 24 Jul 2006 06:58:04 +0000 (GMT) (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 71200109A2B; Mon, 24 Jul 2006 16:58:02 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k6O6vvNm018897; Mon, 24 Jul 2006 16:57:59 +1000 Date: Mon, 24 Jul 2006 16:57:57 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Jo Rhett In-Reply-To: <20060721004731.GC8868@svcolo.com> Message-ID: <20060724154856.I58894@delplex.bde.org> References: <20060721000018.GA99237@svcolo.com> <20060721001607.GA64376@megan.kiwi-computer.com> <20060721004731.GC8868@svcolo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Rick C. Petty" , freebsd-hardware@FreeBSD.org Subject: Re: device busy -- no locks? X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 06:58:05 -0000 On Thu, 20 Jul 2006, Jo Rhett wrote: > Thanks for the super-quick reply! Responses are inline... > > On Thu, Jul 20, 2006 at 07:16:07PM -0500, Rick C. Petty wrote: >>> root@scapa 47# fstat /dev/ttyd0 >>> USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME >> >> What about "fstat /dev/cuad0" ? Anyway, I've found that fstat is useless, >> try using sysutils/lsof instead. This is related to a longstanding (design) bug in vfs (first-open/last-close semantics). vfs counts devices as being open when it calls the device open routine, despite devices not actually being open until the device open routine returns successfully, which may happen much later (or not at all in the case of failure, but this doesn't cause any additional problems). This causes the device close routine to not be called in some cases where it should be. For bidirectional serial devices, not calling the device close routine results in "callin" devices that are sleeping in open being treated the same as "callin" devices that have successfully completed the open. The former shouldn't give EBUSY for opens of the corresponding "callout" device, but the latter should and do. FreeBSD-1 has a hack to vfs to work around the bug, but the hack was lost in FreeBSD-2. I still use the hack locally. Startting with about FreeBSD-4, there is a D_TRACKCLOSE device flag that can be used to fix the problem less hackishly (but still not in the right way, since it requires individual drivers to do generic things). I haven't got around to using it to fix sio even locally. D_TRACKCLOSE is mostly unused and mostly used bogusly when it is used. The bug rarely causes problems since it is only activated by doing something like the following: thread1: "open" /dev/ttyd0. Actually, block in open waiting for carrier. thread2: open /dev/ttyd0 using O_NONBLOCK to prevent blocking. thread2: perhaps actually use /dev/ttyd0 thread2: "close" /dev/ttyd0. Actually, don't complete the close due to the bogus vfs close. thread1: remain blocked in open through all the above. thread3: try to open /dev/cuaa^Hd0. Get EBUSY because the non-open by thread1 is seen as an open. Starting with about FreeBSD-5, there may be additional problems from races. First-open/last-close semantics basically require opens to be synchronous. Sleeping in open for serial device drivers gives large race windows in which to open may race open/close of the same device in other threads. Prempting the kernel gives small race windows. In practice, Giant locking limits problems. For serial drivers, open/close should still be Giant- locked since the whole tty subsystem is still Giant-locked. (Note that all vfs locks are dropped before calling device open/close. The bogus vfs count provides some psuedo-locking.) Rearrangement of serial drivers in -current may have enlarged the bug, but I can't see any enlargement except that from more serial drivers now supporting bidirectional devices. > Sorry, yes. Same results. And if lsof shows things that fstat doesn't, > then this is a bug in FreeBSD. > > But anyway, > root@scapa 63# lsof /dev/cuad0 > root@scapa 64# lsof /dev/ttyd0 > > Nada. I think fstat and lsof can't see threads sleeping in open since the open hasn't really completed -- the open has completed enough to confuse vfs but not for vfs to report its confusion to userland. It should be possible to see threads sleeping in open using "ps -lax | grep ttydcd" ("ttydcd" is the string for -current; the string for sio used to be "siodcd". Grep for "tty" and "dcd" too). This won't distinguish between threads sleeping normally in open (ttyopen) and ones that are in a bogus state due to a missing close. > Also note that this system is pretty bone stock. Standard install, plus > mysql and apache. Nothing else would be using the port. It's something > that left it locked, and really only "login" could be the culprit. Quite likely, but login doesn't use O_NONBLOCK so I don't know how it could trigger the bug. Maybe nopise on DCD cound do it. The easiest way to trigger the bug is "stty -f /dev/ttyd0" while there is a login blocked in open on ttyd0. >>> No locks? No processes using it. Okay, this is uncool. >>> And yet "ktrace tip com1" and "kdump -f ktrace.out" clearly show: >>> >>> 50461 tip CALL open(0x8059030,0x6,0) >>> 50461 tip NAMI "/dev/cuad0" >>> 50461 tip RET open -1 errno 16 Device busy >> >> This isn't very useful. A ktrace on the process that's locking the file >> would be. :-P > > See above. I can't find it. :-( You might need to start ktracing very early to locate the original problematic open/open/close sequence. >>> NOTE: at this time I am suspecting that CD is being misread (it's not >>> present - I have a break out box on the line) and that this problem is >>> somehow tied to that. This problem appears at random after login has >>> exerted itself on the system. I've disabled the getty on ttyd0 and login >>> has timed out, but it continues to show "device busy". >> >> How did you disable the getty? Was this prior to or after a restart? It >> sounds like /etc/ttys is maybe running a process on it. You need to >> "killall -HUP init" after changing /etc/ttys. But you probably already >> know that. > > Yes, I change "on" to "off" in /etc/ttys and "kill -1 1" :-) Killing all processes sleeping in serial device open unwedges the port for the bug that I know about (provided the close doesn't hang). This and making the open succeed by raising DCD in hardware are the only ways that I know of to unwedge the port once the open gets stuck. Bruce From owner-freebsd-hardware@FreeBSD.ORG Mon Jul 24 16:07:38 2006 Return-Path: X-Original-To: freebsd-hardware@FreeBSD.ORG Delivered-To: freebsd-hardware@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F68416A4E1 for ; Mon, 24 Jul 2006 16:07:38 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8324143D70 for ; Mon, 24 Jul 2006 16:07:37 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (mzsxer@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k6OG7U0T054584 for ; Mon, 24 Jul 2006 18:07:36 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k6OG7U0h054583; Mon, 24 Jul 2006 18:07:30 +0200 (CEST) (envelope-from olli) Date: Mon, 24 Jul 2006 18:07:30 +0200 (CEST) Message-Id: <200607241607.k6OG7U0h054583@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hardware@FreeBSD.ORG In-Reply-To: <1153530126.1977@origin.intron.ac> X-Newsgroups: list.freebsd-hardware User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 24 Jul 2006 18:07:36 +0200 (CEST) Cc: Subject: Re: Improving FreeBSD's hardware compatibility X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hardware@FreeBSD.ORG List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 16:07:38 -0000 Intron wrote: > Oliver Fromme wrote: > > Intron wrote: > > > Do you believe that current Intel Pentium 4 or AMD Athlon XP can process > > > analog TV in full frame size and full frame rate (no larger than 767x575, > > > 25 FPS, either of NTSC/PAL/SECAM) freely? > > > > My 7-years old Pentium-II can do that. > > Really? Yes. It has an old bt848 PCI card and is perfectly capable of receiving analog TV. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "IRIX is about as stable as a one-legged drunk with hypothermia in a four-hundred mile per hour wind, balancing on a banana peel on a greased cookie sheet -- when someone throws him an elephant with bad breath and a worse temper." -- Ralf Hildebrandt From owner-freebsd-hardware@FreeBSD.ORG Mon Jul 24 16:19:06 2006 Return-Path: X-Original-To: freebsd-hardware@freebsd.org Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07D5116A4DA for ; Mon, 24 Jul 2006 16:19:06 +0000 (UTC) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2DBF43D45 for ; Mon, 24 Jul 2006 16:19:05 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k6OGJ5ih021998; Mon, 24 Jul 2006 09:19:05 -0700 (PDT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k6OGJ4lj091657; Mon, 24 Jul 2006 09:19:04 -0700 (PDT) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k6OGJ4bN091654; Mon, 24 Jul 2006 09:19:04 -0700 (PDT) (envelope-from jrhett) Date: Mon, 24 Jul 2006 09:19:04 -0700 From: Jo Rhett To: Bruce Evans Message-ID: <20060724161904.GA86330@svcolo.com> References: <20060721000018.GA99237@svcolo.com> <20060721001607.GA64376@megan.kiwi-computer.com> <20060721004731.GC8868@svcolo.com> <20060724154856.I58894@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060724154856.I58894@delplex.bde.org> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: "Rick C. Petty" , freebsd-hardware@freebsd.org Subject: Re: device busy -- no locks? X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 16:19:06 -0000 Thank you for the detailed reply. My answers are inline. On Mon, Jul 24, 2006 at 04:57:57PM +1000, Bruce Evans wrote: > This is related to a longstanding (design) bug in vfs (first-open/last-close > semantics). vfs counts devices as being open when it calls the device > open routine, despite devices not actually being open until the device > open routine returns successfully, which may happen much later (or not > at all in the case of failure, but this doesn't cause any additional > problems). This causes the device close routine to not be called in > some cases where it should be. For bidirectional serial devices, not > calling the device close routine results in "callin" devices that are > sleeping in open being treated the same as "callin" devices that have > successfully completed the open. The former shouldn't give EBUSY for > opens of the corresponding "callout" device, but the latter should and > do. > > FreeBSD-1 has a hack to vfs to work around the bug, but the hack was > lost in FreeBSD-2. I still use the hack locally. Startting with about > FreeBSD-4, there is a D_TRACKCLOSE device flag that can be used to fix > the problem less hackishly (but still not in the right way, since it > requires individual drivers to do generic things). I haven't got around > to using it to fix sio even locally. D_TRACKCLOSE is mostly unused and > mostly used bogusly when it is used. > > The bug rarely causes problems since it is only activated by doing > something like the following: > > thread1: "open" /dev/ttyd0. Actually, block in open waiting for > carrier. > thread2: open /dev/ttyd0 using O_NONBLOCK to prevent blocking. > thread2: perhaps actually use /dev/ttyd0 > thread2: "close" /dev/ttyd0. Actually, don't complete the close due to > the bogus vfs close. > thread1: remain blocked in open through all the above. > thread3: try to open /dev/cuaa^Hd0. Get EBUSY because the non-open by > thread1 is seen as an open. Well in this case it's a simple/standard/stock "getty" and qpage trying to use the same phone line. > Starting with about FreeBSD-5, there may be additional problems from races. > First-open/last-close semantics basically require opens to be synchronous. > Sleeping in open for serial device drivers gives large race windows in > which to open may race open/close of the same device in other threads. > Prempting the kernel gives small race windows. In practice, Giant locking > limits problems. For serial drivers, open/close should still be Giant- > locked since the whole tty subsystem is still Giant-locked. (Note that > all vfs locks are dropped before calling device open/close. The bogus vfs > count provides some psuedo-locking.) Okay, you lost me here. Is there anything I can do about this? Patch qpage to use giant-locks? > I think fstat and lsof can't see threads sleeping in open since the open > hasn't really completed -- the open has completed enough to confuse vfs > but not for vfs to report its confusion to userland. It should be possible > to see threads sleeping in open using "ps -lax | grep ttydcd" ("ttydcd" is > the string for -current; the string for sio used to be "siodcd". Grep for > "tty" and "dcd" too). This won't distinguish between threads sleeping > normally in open (ttyopen) and ones that are in a bogus state due to a > missing close. For the record, 6.0-REL is apparently using ttydcd root@arran 3# ps -lax |grep dcd 0 11571 1 0 5 0 1260 792 ttydcd S ?? 0:00.00 /usr/libexec/getty std.9600 ttyd0 > Quite likely, but login doesn't use O_NONBLOCK so I don't know how it > could trigger the bug. Maybe nopise on DCD cound do it. The easiest > way to trigger the bug is "stty -f /dev/ttyd0" while there is a login > blocked in open on ttyd0. Ah... so that's why it happened so often while I was testing last Thursday. I was checking the tty state while working on the problem, and... > Killing all processes sleeping in serial device open unwedges the port for > the bug that I know about (provided the close doesn't hang). This and Hm. We have seen a repeated and oft-repeatable situation where getty will start login on the port, and we try to kill login to clear it. login hangs, and stays in a zombie state for up to a full day. Related? > making the open succeed by raising DCD in hardware are the only ways that > I know of to unwedge the port once the open gets stuck. Very good to know. That will make testing this problem much easier. (reboots must be scheduled weeks in advance, so...) Yes, I am trying to build a test system we can use to replicate/play with this bug. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-hardware@FreeBSD.ORG Mon Jul 24 20:58:10 2006 Return-Path: X-Original-To: freebsd-hardware@freebsd.org Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B59AB16A4E0 for ; Mon, 24 Jul 2006 20:58:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2462E43D72 for ; Mon, 24 Jul 2006 20:57:59 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6OKvo6o028334; Mon, 24 Jul 2006 16:57:53 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hardware@freebsd.org Date: Mon, 24 Jul 2006 16:46:10 -0400 User-Agent: KMail/1.9.1 References: <20060721045029.GL96589@funkthat.com> <1153463627.84529@origin.intron.ac> In-Reply-To: <1153463627.84529@origin.intron.ac> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607241646.10909.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 24 Jul 2006 16:57:55 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1616/Mon Jul 24 13:49:29 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: John-Mark Gurney , Intron Subject: Re: Improving FreeBSD's hardware compatibility X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 20:58:10 -0000 On Friday 21 July 2006 02:19, Intron wrote: > >> 3. Philips SAA 7130/7134, TV decoder > >> This is one of the most popular TV decoder chips on the market. > >> The data sheet can be obtained from the vendor, just as what Linux > >> community has done. > > > > analog TV? what's that? isn't everyone going digital? (yes, I know > > that analog TV will be with us for a long time due to security cams > > and other uses..) > > Do you believe that current Intel Pentium 4 or AMD Athlon XP can process > analog TV in full frame size and full frame rate (no larger than 767x575, > 25 FPS, either of NTSC/PAL/SECAM) freely? Umm, quite certain actually. If you are ever in the US with cable, go turn on The Weather Channel. If you are in a modestly large market (such as a city) then every frame of video you see is being rendered on a Pentium 4-based PC at the NTSC standard 29.97 FPS (or whatever the exact number is). :) > Do you really believe that current Intel Pentium 4 or AMD Athlon XP > can process much higher bitstream HDTV? In my experience the bottleneck is not the CPU, but bus bandwidth. PCI-e has a lot more bandwidth than PCI. PCI-e should be sufficient for HD. -- John Baldwin From owner-freebsd-hardware@FreeBSD.ORG Tue Jul 25 20:22:34 2006 Return-Path: X-Original-To: freebsd-hardware@FreeBSD.org Delivered-To: freebsd-hardware@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45F0816A53F for ; Tue, 25 Jul 2006 20:22:34 +0000 (UTC) (envelope-from jrhett@svcolo.com) Received: from outbound0.sv.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47CDA43D7B for ; Tue, 25 Jul 2006 20:22:25 +0000 (GMT) (envelope-from jrhett@svcolo.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k6PKMNis033967; Tue, 25 Jul 2006 13:22:24 -0700 (PDT) (envelope-from jrhett@svcolo.com) Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k6PKMJAv088401; Tue, 25 Jul 2006 13:22:19 -0700 (PDT) (envelope-from jrhett@svcolo.com) In-Reply-To: <20060724154856.I58894@delplex.bde.org> References: <20060721000018.GA99237@svcolo.com> <20060721001607.GA64376@megan.kiwi-computer.com> <20060721004731.GC8868@svcolo.com> <20060724154856.I58894@delplex.bde.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8B9E167C-89DC-4CC7-84E6-4339AA443574@svcolo.com> Content-Transfer-Encoding: 7bit From: Jo Rhett Date: Tue, 25 Jul 2006 13:22:00 -0700 To: Bruce Evans X-Mailer: Apple Mail (2.752.2) Cc: "Rick C. Petty" , freebsd-hardware@FreeBSD.org Subject: Re: device busy -- no locks? X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 20:22:34 -0000 On Jul 23, 2006, at 11:57 PM, Bruce Evans wrote: > Killing all processes sleeping in serial device open unwedges the > port for > the bug that I know about (provided the close doesn't hang). This and > making the open succeed by raising DCD in hardware are the only > ways that > I know of to unwedge the port once the open gets stuck. Hm. So I just noticed that ttyd0 was locked even though nothing was using it. I shut down qpage and disabled the getty (vi /etc/ttys and kill -1 1) and now there's no processes to use it and its still locked. Anything else I can gather to help debug this? Or in particular, get a bug open on this and perhaps get it fixed? -- Jo Rhett senior geek Silicon Valley Colocation From owner-freebsd-hardware@FreeBSD.ORG Wed Jul 26 04:31:21 2006 Return-Path: X-Original-To: freebsd-hardware@freebsd.org Delivered-To: freebsd-hardware@freebsd.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id D188116A4DD for ; Wed, 26 Jul 2006 04:31:21 +0000 (UTC) (envelope-from owner-freebsd-isp@freebsd.org) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: owner-freebsd-isp@freebsd.org To: freebsd-hardware@freebsd.org Message-ID: Date: Wed, 26 Jul 2006 04:31:20 +0000 Precedence: bulk X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 X-List-Administrivia: yes Sender: owner-freebsd-isp@freebsd.org Errors-To: owner-freebsd-isp@freebsd.org Subject: Your message to freebsd-isp awaits moderator approval X-BeenThere: freebsd-hardware@freebsd.org List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 04:31:21 -0000 Your mail to 'freebsd-isp' with the subject You have the experience but lack the proper University Degree. Is being held until the list moderator can review it for approval. The reason it is being held: SpamAssassin identified this message as possible spam Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.freebsd.org/mailman/confirm/freebsd-isp/34f180c4a171076723bb32487cedf569c1a75ffc PLEASE NOTE! If you would like to post freely to the list, please subscribe first. If you post from multiple addresses, you can subscribe each address and go into the options page and select 'no mail' for all but one address. This will allow you to post without delay in the future. Sorry for the hassle, but certain immature people made this necessary. From owner-freebsd-hardware@FreeBSD.ORG Wed Jul 26 15:27:31 2006 Return-Path: X-Original-To: freebsd-hardware@freebsd.org Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D83F16A4DD for ; Wed, 26 Jul 2006 15:27:31 +0000 (UTC) (envelope-from darrendavid@thebomb.com) Received: from citiz3n.com (mail.citiz3n.com [66.98.202.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2554143D8B for ; Wed, 26 Jul 2006 15:27:19 +0000 (GMT) (envelope-from darrendavid@thebomb.com) Received: (qmail 54233 invoked by uid 89); 26 Jul 2006 15:27:19 -0000 Received: from dsl092-017-251.sfo4.dsl.speakeasy.net (HELO ?10.0.1.100?) (darren@citiz3n.com@66.92.17.251) by 0 with ESMTPA; 26 Jul 2006 15:27:19 -0000 Message-ID: <44C789D9.2050008@thebomb.com> Date: Wed, 26 Jul 2006 08:27:21 -0700 From: Darren David User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: freebsd-hardware@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: FreeBSD 6.1 installer doesn't recognize ICH5R RAID1 X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 15:27:31 -0000 hi all- I had also posted this message to freebsd-questions, but thought this might be a more appropriate list, so apologies if some of you are seeing double. I'm doing a clean install to 6.1, and i've decided to set up my system drives as RAID 1 now that I see that 6.1 has support for the ICH5R raid controller. My BIOS recognizes the SATA RAID 1 array correctly, but the FreeBSD installer still sees 'ad4' and 'ad6' as two separate drives. The installer has no problem with my 3ware 9500-based RAID5 array. FWIW, ad4 and ad6 both have old installs of freebsd 5.4 on them, including bootloaders, not sure if that's causing some of the confusion here. should i format the RAID1 array first using the Intel utility? or should i just look to gmirror? thanks in advance, darren david From owner-freebsd-hardware@FreeBSD.ORG Fri Jul 28 11:05:24 2006 Return-Path: X-Original-To: freebsd-hardware@freebsd.org Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 009F916A4DA for ; Fri, 28 Jul 2006 11:05:23 +0000 (UTC) (envelope-from mranner@inode.at) Received: from files.jawa.at (jawa.at [213.229.17.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1318043DBB for ; Fri, 28 Jul 2006 11:03:20 +0000 (GMT) (envelope-from mranner@inode.at) Received: from localhost (localhost [127.0.0.1]) by files.jawa.at (Postfix) with ESMTP id F2593173BC for ; Fri, 28 Jul 2006 13:03:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jawa.at Received: from files.jawa.at ([127.0.0.1]) by localhost (files.jawa.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QE006HiCw88i for ; Fri, 28 Jul 2006 13:03:14 +0200 (CEST) Received: by files.jawa.at (Postfix, from userid 60) id A0B16173B7; Fri, 28 Jul 2006 13:03:14 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on files.jawa.at X-Spam-Level: X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from walgrind.jawa.at (walgrind.jawa.at [192.168.200.56]) by files.jawa.at (Postfix) with ESMTP id ED45617371 for ; Fri, 28 Jul 2006 13:03:11 +0200 (CEST) From: Michael Ranner To: freebsd-hardware@freebsd.org Date: Fri, 28 Jul 2006 13:03:09 +0200 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607281303.09720.mranner@inode.at> Subject: ICH7 SATA controller on HP nx7400 does not find disc X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 11:05:24 -0000 Hello! I have already searched Google and the mailing list archive, and found there were some problems with ICH7 SATA in the past months. I got my brandnew HP nx7400 notebook today and tried to install FreeBSD 6.1-RELEASE. The kernel shows the SATA controller, but does not recognize the SATA disc. IDE CDROM works properly. The BIOS offers a feature to put the SATA controller in compatibilty mode, but I am not very happy with this, because only UDMA33 is available instead of SATA150 and SATA300. Any ideas? -- /\/\ichael Ranner mranner@inode.at - mranner@jawa.at - mranner@bugat.at ----------------------------------------------------- BSD Usergroup Austria - http://www.bugat.at/ -----BEGIN GEEK CODE BLOCK----- GIT/CS/AT dx(-) s+:(++:) a- C++ UBLVS++++$ P++>+++$ L-(+)$ E--- W+++$ N+(++) o-- K- w--()$ O-(--) M@ V-(--) PS+>++ PE(-) Y+ PGP(-) t+ 5+ X+++(++++) R* tv++ b+(++) DI++ D-(--) G- e h--(*) r++ y? ------END GEEK CODE BLOCK------ From owner-freebsd-hardware@FreeBSD.ORG Sat Jul 29 22:58:54 2006 Return-Path: X-Original-To: freebsd-hardware@freebsd.org Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC64F16A4DD for ; Sat, 29 Jul 2006 22:58:54 +0000 (UTC) (envelope-from tommarnk@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FCAD43D45 for ; Sat, 29 Jul 2006 22:58:53 +0000 (GMT) (envelope-from tommarnk@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so250332uge for ; Sat, 29 Jul 2006 15:58:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:to:subject:from:organization:content-type:mime-version:content-transfer-encoding:message-id:user-agent; b=PqcmBM+DhuU7ZAq2Hgr9pXCdtV1qyPFafYJLxatR7/vgmBol7b+4edtQmUz+xyqHhoF1fiTU8WcAIwlbiGuezTz9qBavHyaUvwTEkRQCWD/yvgw8xdrluVWjCPFxXNv9CoJbzgpKqaWFPE8xPWtB5gJm4CvyGuISxNU02Iw4rVU= Received: by 10.66.249.11 with SMTP id w11mr1043828ugh; Sat, 29 Jul 2006 15:58:52 -0700 (PDT) Received: from wiak.lan ( [80.202.189.55]) by mx.gmail.com with ESMTP id h1sm3159341ugf.2006.07.29.15.58.52; Sat, 29 Jul 2006 15:58:52 -0700 (PDT) Date: Sun, 30 Jul 2006 00:58:48 +0200 To: freebsd-hardware@freebsd.org From: wiak Organization: nwgat Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: User-Agent: Opera Mail/9.01 (Win32) Subject: server hardware X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 22:58:54 -0000 Am gonna build a new sever soon but will this setup support FreeBSD 6.1 AMD64? - - - - - - - - - - - - - - - AMD Opteron 170 Dual Core (S939, 2,0GHz, 2MB, Boxed) 2x Western Digital Raptor WD740ADFD, 73GB (10000rpm, SATA, 16MB) 2GB PC3200 DDR ECC Reg. CL3 (Kingston KVR400D4R3A/2G) Chieftec UNC-110S-B (1U, ATX, 220W, Zwart) Tyan Tomcat K8E, nForce4 (Sound, LAN, SATA II, RAID, 1394, VGA) - - - - - - - - - - - - - - - -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/