Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!rice!rice!sun-spots-request From: geof@aurora.com (Geoffrey H. Cooper) Newsgroups: comp.sys.sun Subject: Re: vmunix: zs0: parity error ignored (summ Keywords: SunOS Message-ID: <1990Aug2.002544.16791@rice.edu> Date: 1 Aug 90 16:51:37 GMT Sender: sun-spots-request@rice.edu Organization: Sun-Spots Lines: 84 Approved: Sun-Spots@rice.edu Originator: spots@titan.rice.edu X-Sun-Spots-Digest: Volume 9, Issue 285, message 7 X-Refs: Original: v9n281 OK, not many responses on this one, but I got tired and tried my fix. 16 hours later, everything seems fine, and I don't get these messages anymore. Obviously, I am not giving a warranty! The problem is a plethora of random messages from one of the serial ports. Sun customer support reports that this condition was always happening, but that the message wasn't getting logged until 4.1. The message looks like: Jul 28 05:00:14 aurora vmunix: zs0: parity error ignored Jul 28 05:00:43 aurora vmunix: zs0: parity error ignored Jul 28 05:00:43 aurora last message repeated 2 times Jul 28 06:05:37 aurora vmunix: zs0: parity error ignored and so on. Zs0 means port A and Zs1 means port B (I get it only on zs0, but others report zs1). Well, if the only difference is that the message is being logged now, this is something I can fix! 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 did this: # 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 [note: ADB patches right away, so if you blow it, revert to vmunix.save and repeat the entire procedure. If the system won't boot, boot sd()-a, respond with returns to everything except the BOOT: message, where you type "vmunix.save"] geof@aurora.com / aurora!geof@decwrl.dec.com / geof%aurora.com@decwrl.dec.com X-From: sjk@nil.UUCP (Scott J. Kramer) We've got the same lossage on our Sun-3/180, SunOS 4.1 system with Telebit Trailblazer+ and Supra 2400 modems on the a & b serial ports. What's puzzling to me is why it also happens on zs1: Jul 25 04:42:02 pixar vmunix: zs0: parity error ignored Jul 25 05:53:47 pixar vmunix: zs1: parity error ignored Jul 25 06:32:22 pixar vmunix: zs1: parity error went up and that "... went up" message is peculiar, too. Another problem is that the Supra modem on the b port (currently the first line in a 4-number dialup rotary (we've got two other Supra's on a CoALM board)) goes into limbo about once a day and requires power-cycling to clear it; "ATZ"ing it is futile. This prevents anyone from dialing in until it's reset since our UUCP incallers only use that first number. I've unsuccessfully tried several combinations of modems and ports; I still can't tell whether it's a hardware and/or software problem. A few of the incoming/outgoing calls are at 1200bps and I suspect that the trouble is related to the modems and/or serial lines not properly resetting. At first I thought the "modem in limbo" problem was related to the parity error stuff, but there doesn't seem to be any correlation. So I can't tell you what those kernel messages really mean (sure is a loss not having system source!), tho' I'm anxious to find out! Scott J. Kramer inet: pixar!sjk@ucbvax.Berkeley.EDU Pixar uucp: ...!{sun,ucbvax}!pixar!sjk 1001 West Cutting Boulevard voice: 415-236-4000 Richmond, CA, 94804 USA -- geof@aurora.com / aurora!geof@decwrl.dec.com / geof%aurora.com@decwrl.dec.com