From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 20:05:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E750316A4CE; Sun, 18 Jul 2004 20:05:10 +0000 (GMT) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 133DE43D45; Sun, 18 Jul 2004 20:05:10 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from ns0.nlsystems.com (ns0.nlsystems.com [80.177.232.243]) by itchy.rabson.org (8.12.11/8.12.11) with ESMTP id i6IK4wPc051041; Sun, 18 Jul 2004 21:04:59 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Andrew Gallatin Date: Sun, 18 Jul 2004 21:04:53 +0100 User-Agent: KMail/1.6.1 References: <16634.47272.768935.436137@grasshopper.cs.duke.edu> <200407182039.10773.dfr@nlsystems.com> <16634.54674.966908.540880@grasshopper.cs.duke.edu> In-Reply-To: <16634.54674.966908.540880@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200407182104.53221.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on itchy.rabson.org X-Virus-Scanned: clamd / ClamAV version 0.71, clamav-milter version 0.71 X-Virus-Status: Clean cc: simokawa@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Excellent job on the firewire support! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2004 20:05:11 -0000 On Sunday 18 July 2004 20:54, Andrew Gallatin wrote: > Doug Rabson writes: > > On Sunday 18 July 2004 18:51, Andrew Gallatin wrote: > > > Hi, > > > > > > I just wanted to say that I used FreeBSD's firewire and sbp-II > > > support for the first time this weekend. It seems to be fast > > > (over 26MB/sec writes, 34MB/sec reads to a LaCie 160GB drive), > > > and robust. It works well on non-i386 platforms -- I'm using it > > > to back up an amd64, and to serve as a root device for a > > > FreeBSD/powerpc machine. > > > > > > All in all, it totally exceeded my expectations. Thank you very > > > much| > > > > Wait till you try debugging using gdb over firewire with dcons. An > > all round positive experience :-) > > It would be nice to remove my Comtrol Rocketport serial card, and the > 8 serial cables leading across the middle of the room to my shelf of > machines and replace it with one firewire cable leading to a firewire > hub. But, as a firewire newbie, I have some questions: > > 1) Is any firewire PCI adapter just as good as any other in terms of > performance, and FreeBSD support? (prices seem to range from $10 > to $100) Any should do about as well as any other. I probably wouldn't want to spend more than ~$50 on one. > > 2) Is dcons usable after a panic (ie, DDB or KDB_TRACE)? Or is it > only usable for remote-gdb? Dcons provides two full duplex streams - one for console and one for gdb. You can use DDB on the console just like normal. > > 3) Is dcons endian and pointer-size agonstic? Can I run consoles to > an amd64 and a powerpc box from an x86? I haven't actually tried that and I imagine that there might be issues here and there. Any problems are likely to be in the dconschat program but that should be pretty easy to fix since its entirely userland. > > 4) Does the loader know about dcons? Eg, can I do "unload boot > kernel.test" using dcons? Actually thats the only downside of dcons. It doesn't cut in until the firewire controller attaches. It relies on the fact that the fwohci driver allows access to physical memory from any node on the bus (implemeted in hardware so you can examine the memory of a hung machine). The dconschat program uses this feature to access the dcons ring buffers in the target machine. I could imagine a dcons driver in the loader which just enabled physical access and used some kind of loader trick to hand off the ring buffers to the kernel dcons driver. It doesn't exist though - say nice things to the author and he might find the time for it :-)