I've done some poking around with the driver and found that the line

     cp = getpropstringA(node, prop, buffer, sizeof buffer);

   returns a null string to cp.  When I examined the full length of buffer[]
   I found that it was just full of garbage.  I'm still digging my way
   through function calls to figure out where things are breaking down.

I am the one who wrote the original PR and can confirm the above
behavior.  The buffer returned is junk.

The problem almost seems to be prom version dependent, as it does not
appear to exist on any of my other Suns [if I recall correctly], only on
my SS2.  I would also state that the eeprom command says that input-device
and output-device are set to ttya.

Also...  this, did at one time, function as expected.  I am not sure when
it went amuck.

   In the meantime, can someone give me an example of what the cp string
   should look like for the serial console on ttya?

   Thanks.

   -brian.


   On Mon, 1 Nov 1999, David Brownlee wrote:

   > 	http://www.NetBSD.org/cgi-bin/query-pr-single.pl?number=7409
   > 
   > 	Could someone with this problem please change line 919 of
   > 	/sys/arch/sparc/dev/zs.c to
   > 
   >         printf("Warning: unparseable %s property '%s'\n", prop, buffer);
   > 
   > 	and report the new error messages.
   > 
   > 	My guess is the following commit is the problem:
   > 
   > http://cvsweb.netbsd.org/cgi-bin/cvsweb.cgi/syssrc/sys/arch/sparc/dev/zs.c.diff?r1=1.65&r2=1.66
   > 
   > 		David/absolute
   > 


[snip]




Brad Spencer - brad@anduin.eldar.org   http://anduin.eldar.org
[finger brad@anduin.eldar.org for PGP public key]