From owner-cvs-all@FreeBSD.ORG Fri Mar 11 08:37:49 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0298716A4CE; Fri, 11 Mar 2005 08:37:49 +0000 (GMT) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68B1543D2D; Fri, 11 Mar 2005 08:37:48 +0000 (GMT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) j2B8bkJB057958; Fri, 11 Mar 2005 09:37:46 +0100 (CET) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.11/8.12.10/Submit) id j2B8bfaB057957; Fri, 11 Mar 2005 09:37:41 +0100 (CET) (envelope-from marius) Date: Fri, 11 Mar 2005 09:37:40 +0100 From: Marius Strobl To: "David O'Brien" Message-ID: <20050311093740.B55534@newtrinity.zeist.de> References: <200501300927.j0U9RnQU008885@repoman.freebsd.org> <20050310193237.GA52299@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20050310193237.GA52299@dragon.nuxi.com>; from obrien@freebsd.org on Thu, Mar 10, 2005 at 11:32:37AM -0800 X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-6; AVE: 6.30.0.5; VDF: 6.30.0.25; host: newtrinity.zeist.de) cc: cvs-src@freebsd.org cc: Marcel Moolenaar cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/sparc64/conf GENERIC X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2005 08:37:49 -0000 On Thu, Mar 10, 2005 at 11:32:37AM -0800, David O'Brien wrote: > On Sun, Jan 30, 2005 at 09:27:49AM +0000, Marcel Moolenaar wrote: > > marcel 2005-01-30 09:27:49 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/sparc64/conf GENERIC > > Log: > > o Enable puc(4) and uart(4). > > o Disable ofw_console(4), sab(4) and zs(4). > .. > > ofw_console(4) is disabled because it doesn't claim the device it > > controls (through OFW) and thus interferes with puc(4)+uart(4), > > which has sufficient knowledge to extract the necessary information > > from OFW to setup the console. Put differently, ofw_console(4) is > > not a proper device driver and can only do harm. Its functionality > > is completely handled by uart(4). > > Please Back commit out. You broke the console on the most modern Sparc > machines we run^H^Hran on. Commenting out uart adding back > ofw_console(4) restore console on Sun Blade 1{0,5}0 machines. Just > adding back ofw_console(4) restores console output, but ofw_console(4) > and uart(4) fight for input. This sounds unlikely, uart(4) was reported to work on Sun Blade 100 in the past and the recent changes were tested on a Sun AX1105 (the ATX version of the Blade 100 mainboard) and a Sun Fire V100 which also uses NS16550 on an ISA bus like the Blade 100. It's more likely a configuration problem, please make sure that ttyu[0,1] are enabled in /etc/ttys but nothing else and that input-device and output-device are set to either ttya or ttyb in the OFW boot prompt or via eeprom(8). Anyway, we generally give a chance to fix the problem in case a change causes a breakage instead of calling for a back out immediately and you are the first to report a breakage on this type of hardware. So in case this really is a problem with uart(4) please let's work on fixing it and walk forward instead of backward. > > Contrary to rev 1.88's claim, ofw_console(4) does not cause harm, and NO > uart(4) has not completely handled its functionality. > The situation you describe above, i.e. both ofw_console(4) and uart(4) fighting for input, is such a harm. The problems with ofw_console(4) in general are that it doesn't fit together with sc(4)/uart(4) as both try to control the same hardware and that it doesn't attach to the hardware it actually uses and therefore doesn't take part in the probe and attach contest later on. Making this all work together would require layers of hacks to look around corners, e.g. in case there is sc(4) in the kernel we want to make uart(4) handle the Sun keyboard but only if sc(4) can talk to the graphics hardware in that box, otherwise we have to leave both to ofw_console(4). I'd rather work on getting the not yet supported graphics hardware on sparc64 machines to work with sc(4) instead of working on hacks to get ofw_console(4) work and behave properly. As for the claim that uart(4) completely handles the functionality of ofw_console(4) it actually supercedes ofw_console(4) regarding serial devices. Obviously uart(4) doesn't talk to graphics hardware which however works to some extent with ofw_console(4) but using something different from a serial console isn't officially supported by FreeBSD/sparc64 to date. Marius