Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!usc!orion.oac.uci.edu!ucivax!gateway
From: baxter@zola.ICS.UCI.EDU (Ira Baxter)
Newsgroups: comp.unix.i386
Subject: ISC 2.0.2: "PANIC athd_recvdata: LOGIC ERROR missing MEMBREAK"
Message-ID: <9008171007.aa06635@PARIS.ICS.UCI.EDU>
Date: 17 Aug 90 17:10:53 GMT
Lines: 39


I have a Micronics 20Mhz 32kb cache 386 with WD1006SRV2 controller,
running ISC 2.0.2, HPDD configured with the standard file system.
Under normal operation, I get an occasional (1/month) latchup of the WD1006
which I have unsuccessfully been trying to track down for months.  The
latchup causes the disk access light to go on hard, but no disk
activity.  One can use ALT-SYSRQ to switch virtual consoles, so UNIX
is still alive.

One absolutely repeatable experiment is this:
    # Boot up system fresh.  Only this user logged in.
    # place interlace-1 formatted diskette in drive
    cp /dev/dsk/f0q15dt /dev/null
    # wait for above cp to complete
    # You may have to use chmod to make this 0p1 readable
    cp /dev/0p1 /dev/null

After hitting <CR> on the second cp command, I instantly get:
    PANIC athd_recvdata: LOGIC ERROR
    missing MEMBREAK, trying to dump 2464 pages
... and then my WD1006 latches up.

The PANIC looks like a bug in the OS.  It doesn't seem to fail with
/dev/dsk/0p0.   I *do* have a dos partition mounted, which 0p1 is
supposed to represent, but I can't see why that makes a difference.
Can anybody else repeat this?

It appears that the latchup is caused by UNIX trying to do the dump.
Why should the dump logic also be buggy?  My suspicion is that the
UNIX drivers attempt another disk transfer on the drive without
waiting for the previous one to complete, and thus the latchup.
Perhaps another path through the conventional disk drivers make the
same mistake sometimes... this would explain the symptoms I see under
normal operation.

ISC, any comment?

IDB
(714) 856-6693  ICS Dept/ UC Irvine, Irvine CA 92717