Date: Mon, 25 Feb 2013 16:59:10 -0500 From: Chris Ross <cross+freebsd@distal.com> To: Marius Strobl <marius@alchemy.franken.de> Cc: "freebsd-sparc64@freebsd.org" <freebsd-sparc64@freebsd.org> Subject: Re: Problems booting 9.1-STABLE on Netra X1 Message-ID: <3A37672E-B6F7-4D5E-8293-0ED3B203C358@distal.com> In-Reply-To: <20130225214941.GD955@alchemy.franken.de> References: <CE371F2B-CF62-4695-A9F0-B56995BA3CC6@distal.com> <20130225101315.GA79064@alchemy.franken.de> <76C74932-5BB0-4194-86CE-F121F6D18D84@distal.com> <20130225214941.GD955@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 25, 2013, at 4:49 PM, Marius Strobl wrote: > 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. Well, Dave McGuire did respond on that thread that he was running=20 NetBSD 4.0.1 with no problems, but someone else (Jochen Kunz) said they tried netbooting a 4.0.1 kernel on an X1 and got the same hang I did. The code that's in place in the NetBSD tree was actually committed later, it seems, as a result of this other thread that the earlier = thread was resurrected on: http://mail-index.netbsd.org/port-sparc64/2011/02/12/msg001515.html So, at least 2 people, and 3 if I'm reading my personal email archives correctly, have seen this problem on an X1. And, it seems at least one person was _not_ seeing it. (But later seeing some other problem when a CD-ROM was attached to the IDE bus, even when not in use/netbooting) It's clearly low-end hardware, and I could believe that it may be a = "affects some but not all systems". But, assuming it's more than just _one_ = bogus system, finding a way to deal with it at HEAD makes sense. Not = necessarily that the earlier code is the only or best solution. - Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A37672E-B6F7-4D5E-8293-0ED3B203C358>