Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!rice!sun-spots-request
From: geof@aurora.com (Geoffrey H. Cooper)
Newsgroups: comp.sys.sun
Subject: vmunix: zs0: parity error ignored
Keywords: Miscellaneous
Message-ID: <10251@brazos.Rice.edu>
Date: 25 Jul 90 00:58:22 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 39
Approved: Sun-Spots@rice.edu
X-Sun-Spots-Digest: Volume 9, Issue 281, message 7
Originator: spots@titan.rice.edu

I've been getting a lot of these errors ever since I upgraded to SunOS4.1,
both on the machine that has modems and the one that has only a directly
connected printer.  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. 

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.  I'm new at assembly hacking on a SPARC.  Specifically, I don't
know the calling convention.  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

Assuming the sparc keeps the same kind of calling convention as other
machines, this should work.  Anyone not agree with me?  Mail responses to
me, I'll summarize to the net next week.

- Geof

geof@aurora.com / aurora!geof@decwrl.dec.com / geof%aurora.com@decwrl.dec.com