From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 25 21:49:48 2013 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5F71D798 for ; Mon, 25 Feb 2013 21:49:48 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 0C0439E3 for ; Mon, 25 Feb 2013 21:49:47 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.6/8.14.6/ALCHEMY.FRANKEN.DE) with ESMTP id r1PLng2P081764; Mon, 25 Feb 2013 22:49:42 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.6/8.14.6/Submit) id r1PLnfeB081763; Mon, 25 Feb 2013 22:49:41 +0100 (CET) (envelope-from marius) Date: Mon, 25 Feb 2013 22:49:41 +0100 From: Marius Strobl To: Chris Ross Subject: Re: Problems booting 9.1-STABLE on Netra X1 Message-ID: <20130225214941.GD955@alchemy.franken.de> References: <20130225101315.GA79064@alchemy.franken.de> <76C74932-5BB0-4194-86CE-F121F6D18D84@distal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76C74932-5BB0-4194-86CE-F121F6D18D84@distal.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-sparc64@freebsd.org" X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 21:49:48 -0000 On Mon, Feb 25, 2013 at 04:05:42PM -0500, Chris Ross wrote: > > On Feb 25, 2013, at 5:13 AM, Marius Strobl wrote: > > This means that the machine is generating a power failure interrupt, > > which causes FreeBSD to initiate a graceful shutdown rather than > > waiting for the power to supply to suddenly die, which could cause > > data loss. > > In general, it's very model specific whether Sun hooked up that > > interrupt to anything and to what. F.e., in U5/U10 it's just > > connected to the power button rather than a circuit that monitors > > the power supply. I don't know for certain what it is connected to > > in X1. However, given that these latter use an ACPI-style power > > button and were intended as servers, it's quite likely that their > > power failure interrupt actually is connected to a power supply > > monitoring circuit. > > You could hack psycho(4) to just not register the power failure > > interrupt handler. Whether you really want to use that machine in > > this configuration (it could be either the power supply actually > > starting to fail or also just the monitoring circuit being broken) > > is something you have to decide on your own. > > Okay. My memory is sketchy at best, but email is forever. The following > thread, and the second URL to a notable piece there-in where I found a > pointer to the core problem, documents my efforts to get NetBSD running > on this same system 3 years ago. > > http://mail-index.netbsd.org/port-sparc64/2010/05/07/msg001259.html > http://mail-index.netbsd.org/port-sparc64/2010/05/08/msg001267.html > > The solution that I think was to ignore the power fail on this hardware. > A reference in that thread mentions a OpenBSD commit: > > | revision 1.11 > | date: 2002/01/29 20:33:19; author: jason; state: Exp; lines: +3 -1 > | Don't install a handler for powerfail... this causes weird problems with > | the Netra X1 (interactions with lom) > > Numerous things were attempted during the course of that port-sparc64 > netbsd thread, some of which were tied to not installing the handler > in the case of a machine identified as a Netra X1. > > It appears the code in place now in psycho.c is: > > /* > * Netra X1 may hang when the powerfail interrupt is enabled. > */ > if (strcmp(machine_model, "SUNW,UltraAX-i2") != 0) { > psycho_set_intr(sc, 15, psycho_powerfail, > &sc->sc_regs->power_int_map, > &sc->sc_regs->power_clr_int); > psycho_register_power_button(sc); > } > Would that be unacceptable for placing into FreeBSD? Clearly, I can > put it in my own tree for testing and use, but would prefer it live in the > main sources long-term. :-) > Yes, IMO this approach is inappropriate as there really seems to be something broken with this particular machine rather than this issue being a general problem with that model, i.e. nobody else running FreeBSD on an X1 reported this so far. I don't own an X1 but I do have a v100, which employ a mainboard pretty much identical to that of X1 and even also identify themselves as SUNW,UltraAX-i2, but don't see such a problem, i.e. neither the power fail interrupt firing nor strange hangs, either. Once I have a replacement for the broken hardware of my committatron I can make registering the power fail interrupt a tunable defaulting to on though. Marius