Path: utzoo!utgpu!watserv1!watmath!att!cbnewsk!dez
From: dez@cbnewsk.att.com (daniel.e.zuccarelli)
Newsgroups: comp.unix.sysv386
Subject: Re: Adaptec SCSI and Hayes JT FAX 9600
Summary: JT FAX 9600 bug with 32-bit memory access
Message-ID: <1990Sep5.152433.25651@cbnewsk.att.com>
Date: 5 Sep 90 15:24:33 GMT
References: <1990Sep2.213403.5837@pcrat.uucp>
Distribution: na
Organization: AT&T Bell Laboratories
Lines: 63

In article <1990Sep2.213403.5837@pcrat.uucp>, rick@pcrat.uucp (Rick Richardson) writes:
> We have a customer with an Adaptec SCSI controller who is
> trying to install a Hayes JT FAX 9600 fax board in his system.
> Relevant info (that I have) is the following:
> 
> 	3) ISC 2.0.2 UNIX
> 	4) Adaptec SCSI controller
> 	4) All other cards except VGA adapter removed.
> 
> The system crashes or locks up when the Hayes board is installed,
> whether or not a device driver for it has been configured into
> the kernel.  The Hayes board is an 8 bit device, no interrupts,
> no DMA, no I/O ports.  It uses 2K of memory address space
> configurable between 8000:0 and EFFF:0.  Several places have
> been tried (according to the customer), including the default
> 
> The customer says that the lock up occurs after UNIX has been
> booted when the filesystem is mounted, and that the lock-up
> doesn't occur if the filesystem is mounted read-only (!!!???).
> this compatibility problem with the Hayes, which is usually
> one of the least painful boards to add to a system.
> 
> I'm clueless.  Anybody got a clue?  Where's Roy Neese when
> you need him!
> 
> -- 
> Rick Richardson | Looking for FAX software for UNIX/386 ??? Ask About: |Mention

I had the identical problem described above when trying to install the
JT FAX 9600 in an 80386DX NCR machine.  The problem is with the JT FAX
card and the way it handles memory references.  It ignores the control line
that says this is a memory reference and just fires off the shared ram address
being on the address bus with a read or write signal.  This is fine except
that on 1 Meg multiples of the shared ram address it also responds as if it
were being accessed.  The machine I was using had an extended 32-bit bus
for memory only.  When references to physical memory were made above 1 Meg
but at the segment of the shared ram segment, the board tried to pull 
an interrupt which held up the bus until its access was done.  This hosed
the memory reference and caused UNIX to crap out (which was some
version of ISC 386/ix).

I contacted Quadram (at the time) and they said they knew about the problem
and had a fix ready ( very minor), but that because of their recent purchase
by  Hayes, they didn't know if/when it would get implemented.

I dodged the problem by moving to a 386sx machine.  One word of caution, if
you try to get support from Hates/Quadram, get past their technical support
staff at all costs.  I called them initially and described the problem,
upon which they sent me a ROM upgrade !?  I later got in touch with an
engineer who could at least tell me I was on my own.


++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Dan Zuccarelli - AT&T Bell Labs CB/RV
INTERACTIVE Systems Corp.
(614) 860-7023
att!asr1!dez

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Dan Zuccarelli - AT&T Bell Labs CB/RV
INTERACTIVE Systems Corp.
(614) 860-7023