Date: Fri, 11 Mar 2005 09:37:40 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: "David O'Brien" <obrien@freebsd.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/sparc64/conf GENERIC Message-ID: <20050311093740.B55534@newtrinity.zeist.de> In-Reply-To: <20050310193237.GA52299@dragon.nuxi.com>; from obrien@freebsd.org on Thu, Mar 10, 2005 at 11:32:37AM -0800 References: <200501300927.j0U9RnQU008885@repoman.freebsd.org> <20050310193237.GA52299@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050311093740.B55534>