Date: Fri, 11 Mar 2005 10:25:19 -0800 From: "David O'Brien" <obrien@freebsd.org> To: Marius Strobl <marius@alchemy.franken.de> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/sparc64/conf GENERIC Message-ID: <20050311182519.GA8792@dragon.nuxi.com> In-Reply-To: <20050311093740.B55534@newtrinity.zeist.de> References: <200501300927.j0U9RnQU008885@repoman.freebsd.org> <20050310193237.GA52299@dragon.nuxi.com> <20050311093740.B55534@newtrinity.zeist.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 11, 2005 at 09:37:40AM +0100, Marius Strobl wrote:
> 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.
Yes, uart(4) will attach to the serial devices, however one doesn't even
get far enough in the boot to give uart(4) a chance to attach. See the
freebsd-sparc64 mailing list. Just yesterday and today there is a Netra
AX1105-500 owner reporing the same problem.
> 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).
It isn't a configuration problem of mine -- I cannot boot either 5.3 or
6.0 Feb snapshots on ftp.freebsd.org.
The OBP settings are stock:
ok printenv
..snip..
ttyb-mode 9600,8,n,1,- 9600,8,n,1,-
ttya-mode 9600,8,n,1,- 9600,8,n,1,-
output-device screen screen
input-device keyboard keyboard
# diff -s /etc/ttys /usr/src/etc/etc.sparc64/ttys
Files /etc/ttys and /usr/src/etc/etc.sparc64/ttys are identical
> 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.
I will not put much more effort into this issue -- I've already spent
well over 12 hours on it. My console used to work great, this commit
totally broke it. I have other things I need and want to work on.
I tried to warn people that Blade 100/150 were suffieciently different
from U60/10/5's that any change to console support needed testing
specifically on one of these machines. Please point out the tester for
the commit to GENERIC so we can compare environments.
Right now I don't know of anyone that can boot a RELENG_5 snapshot on a
Blade 100/150/AX1105, where such machines could before the GENERIC change
in RELENG_5.
> > 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.
Maybe 5% of our sparc64 users have supported graphic hardware.
The priority is to keep the headless server configurations working above
adding new functionalty.
--
-- David (obrien@FreeBSD.org)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050311182519.GA8792>