vmunix: zs0: parity error ignored

[Greg Earle]

>Sun maintenance reports that lots of people have complained about this but
>that no patch exists.  They say that the problem was always there, and the
>only difference between this and earlier releases is that the message is
>printed.

The reason that no patch exists is because `zs0: parity error ignored' is
a message which is logged to `syslog' at priority level `kern.err'.  If
you look at the default /etc/syslog.conf file, you will see that all
kernel messages of level `kern.debug' and higher (which includes
`kern.err') are logged to the console and /var/adm/messages:

*.err;kern.debug;auth.notice;user.none          /dev/console
*.err;kern.debug;daemon,auth.notice;mail.crit;user.none /var/adm/messages

You will also note that `kern.err' messages will be sent to the user
`operator' if such a user exists and is logged on:

*.alert;kern.err;daemon.err;user.none           operator

What I (speaking for myself, and not for Sun Microsystems, Inc., my
employer) might recommend, for those who are too weak of heart to consider
adb'ing the kernel, is to remove the kernel messages from being sent to
the console and to /var/adm/messages, and instead send them to a file of
their own:

*.err;auth.notice;user.none          /dev/console
*.err;daemon,auth.notice;mail.crit;user.none /var/adm/messages
kern.debug	/var/log/syslog.kernel

or something similar.  This has the deleterious effect of merely keeping
them from blatting on your console; they still fill up just as much disk
space as if they were going to /var/adm/messages, and it makes for one
more logging file to remember/worry about.  On the other hand, "Syslog Is
Your Friend!" and you should take advantage of its capabilities.

On the other hand, if nuking them from the kernel really toots your
whistle ...

>I would like to convince my machine to stop printing this message!
>
>Upon perusal of my /vmunix with my trusty `adb':
>
> _zsa_srint+0x70:                sethi   %hi(0xf80f7c00), %o1
> _zsa_srint+0x74:                or      %o1, 0x153, %o1          ! -0x7f082ad
> _zsa_srint+0x78:                and     %o2, 0x7f, %o2
> _zsa_srint+0x7c:                call    _log
>
> -0x7f082ad?s
> _zsops_async+0x2f:              zs%d: parity error ignored
>
>`strings' confirms that there is only one string of the above form in the
>kernel.

First, note that this is probably a SPARCstation kernel, since a 4/370
GENERIC kernel I just checked had the `call _log' instruction at
`zsa_srint+0x90'.

Secondly, the *second* call to log() in zsa_srint() is the one that emits 

	zs0: parity error went up

which is much less prevalent or commonplace than `parity error ignored',
but one might still wish to supress that as well.

Thus, the *first* *2* calls to log() in each of the following are what you
want to NOP:

	/sys/`arch -k`/OBJ/zs_asynch.o		zsa_srint()

	/sys/`arch -k`/OBJ/mcp_asynch.o		mcpa_srint()

There are also 2 calls to log() for these 2 messages in

	/sys/`arch -k`/OBJ/mti.o		mtiresponse()

(The latter two files/routines handle the cases for the ALM-2 and ALM-1,
respectively; the first - zsa_async.o/zsa_srint() - are for the CPU board
serial ports)

but determining which call to log() corresponds to the 2 desired messages
is a lot harder.  On the Sun-3, the first 2 calls to log() in
mtiresponse() are the calls for the `parity error ignored' and `parity
error went up'; alas, the Sun-4 compiler does something different with the
same code and thus the first 2 calls are not the same.  Hopefully not too
many of you are using an ALM-1 board on a Sun-4 these days (^:

>Looks to me like I should do:
>
>   # cp /vmunix /vmunix.save
>   # adb -w /vmunix
>   _zsa_srint+0x7c?W 0x1000000
>	...xxxxxx = 01000000...
>   _zsa_srint+0x7c?i
>   _zsa_srint+0x7c:     nop
>   ^D
>   # /etc/reboot

I would do instead (for just the simple `zs#: parity error ignored' case)

	# adb -w -k /vmunix /dev/mem
	_zsa_srint+0x7c?W 0x1000000
	    ...xxxxxx = 01000000...
	_zsa_srint+0x7c/W 0x1000000
	    ...xxxxxx = 01000000...
	^D
	# (no need to reboot)

To perma-fix this, you would need to modify the 3 kernel modules that I
mentioned above (along with the 2nd call to log() in each of the
aforementioned functions to kill the `xxx#: parity error went up' case as
well) for future 4.1 kernels.

	- Greg Earle	
	  Sun Microsystems, Inc. - JPL on-site Software Support
	  earle at poseur.JPL.NASA.GOV	(Direct)
	  earle at Sun.COM			(Indirect)