cvs commit: src/sys/sparc64/conf GENERIC

[Marius Strobl]

On Fri, Mar 11, 2005 at 10:25:19AM -0800, David O'Brien wrote:
> 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 GENERIC kernel of 5.3-STABLE-SNAP001 doesn't include uart(4) but
ofw_console(4) etc. (the snapshot was built Jan 30, the switch to
uart(4) was MFC'ed on Feb 15). Despite the fact that I have to disable
DMA for ATAPI 5.3-STABLE-SNAP001 boots fine on an AX1105:
http://alchemy.franken.de/~marius/ax1105_5.3-snap.txt
A GENERIC 5.4-PRERELEASE kernel with uart(4) enabled also works fine
(modulo the compile breakage in the sparc64 vm_machdep.c):
http://alchemy.franken.de/~marius/ax1105_5.4-pre.txt
The GENERIC kernel of 6-CURRENT-SNAP001 comes with uart(4) enabled
and also works:
http://alchemy.franken.de/~marius/ax1105_6.0-snap.txt

> 
> 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

If you want to use a serial console you should set input-device and
output-device to e.g. ttya. Usually when input-device is set to
keyboard and output-device to screen but no keyboard is plugged in
OFW automatically switches to ttya however this doesn't work
reliably on some models. In any case uart(4) honours this settings
(as should ofw_console(4)), i.e. if you have them set like in the
output you posted and a keyboard is plugged in you certainly won't
get a serial console.

> 
> # 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.

If 5.3-STABLE-SNAP001 which uses ofw_console(4) also doesn't work
on your machine than the cause has to be something else. Please try
to set input-device and output-device to ttya like I already requested
in my previous email.

> 
> 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.

I don't have a Blade 100 or 150 available but I'm aware of them and
I'm confident that testing on AX1105 and Fire V100 is sufficient to
ensure that it also works on Blade 100/150.

> 
> 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.

Wrong.

Marius