From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 01:53:00 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 A2E0916A4CE; Tue, 20 Jul 2004 01:53:00 +0000 (GMT) Received: from tora.nunu.org (YahooBB219003182029.bbtec.net [219.3.182.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4141E43D2D; Tue, 20 Jul 2004 01:52:59 +0000 (GMT) (envelope-from simokawa@sat.t.u-tokyo.ac.jp) Received: from tora.nunu.org (unknown [192.168.1.2]) by tora.nunu.org (Postfix) with ESMTP id CE5A94E50F; Tue, 20 Jul 2004 10:52:57 +0900 (JST) Date: Tue, 20 Jul 2004 10:52:57 +0900 Message-ID: <87llhfphqe.wl@tora.nunu.org> From: Hidetoshi Shimokawa To: Doug Rabson In-Reply-To: <200407182104.53221.dfr@nlsystems.com> References: <16634.47272.768935.436137@grasshopper.cs.duke.edu> <200407182039.10773.dfr@nlsystems.com> <16634.54674.966908.540880@grasshopper.cs.duke.edu> <200407182104.53221.dfr@nlsystems.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 MULE XEmacs/21.4 (patch 14) (Reasonable Discussion) (i386--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Tue, 20 Jul 2004 11:46:22 +0000 cc: simokawa@freebsd.org cc: freebsd-current@freebsd.org cc: Andrew Gallatin 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: Tue, 20 Jul 2004 01:53:00 -0000 At Sun, 18 Jul 2004 21:04:53 +0100, Doug Rabson wrote: > > 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. I got some bad report about Lucent chip(some Mac's have it) but I haven't heard any other compatibility issue. I think the price of the adapter doesn't matter but you may have trouble with some bad cables. If have some problem, use lower speed(S100) or change cables. > > > > 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. It's designed for such panic/debugging situation. Actually, it's rather inefficient for usual situation but the speed of FireWire hide the problem ;-) > > > > 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. I should have no problem with 64bit arch and big endian. I have tested with sparc64, powerpc and amd64. > > > > 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 You are right. > to the author and he might find the time for it :-) It is not enough :-< I lack the knowledge of BIOS/PCI(and ACPI?). Once we can access the OHCI register via PCI in the loader, the remaining part is relatively easy as you described. I need some help for this part. I suppose that implementing dcons in the loader is architecture dependent. /\ Hidetoshi Shimokawa \/ simokawa@sat.t.u-tokyo.ac.jp PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html