On Mon, 30 Dec 1996, Markus Baeurle wrote:

> Hi Mark!
> 
> In message <Pine.SGI.3.91.961220194631.12411C-100000@physig4.ph.kcl.ac.uk>
>           Mark Brinicombe <amb@physig.ph.kcl.ac.uk> wrote:
> 
> > I have seen this problem recently but could not find a cause.
> > The indication was that the driver was hanging up waiting for the serial 
> > chip.
> > What happens is when you open it it will try and clear the serial FIFO etc.
> > sometime I found that no matter how many bytes were read from the serial 
> > port the status register indicated there were still bytes present.
> > As only I appeared to be experiencing the problem I had decided that this 
> > was probably a hardware fault with my machine.
> > 
> > I'll have another look at the problem.
> 
> Well I start to remember that the German magazine c't reported problems with
> the FDC37C665. It was quite a long time ago. I looked it up, it was 6/94.
> Revision A to D of the chip won't remove chars in the databuffer if they are
> present when the port is switched to FIFO mode.
> You can get something in the buffer if you switch the modem on after the
> machine which may then send an impulse to the chip.
> 
> I don't know how you can tell which revision of the chip you have and whether
> any of the broken ones were used in the RiscPC at all.
> Mine reads: SMC (R)
>             FDC37C665GT
>             A9429-B247
>             6M73522-3
> Well 9429 is the week when it was manufactured. As I don't have problems,
> broken chips will probably have to be older than mine.
> I don't think GT contains the revision as the chip on the photo in the c't
> carries FDC37C665QF P.
> 
> Hope this helps,

Oh this is very interesting ...
This would explain exactly the behaviour I was seeing. This perhaps 
explains why switching the FIFO off, reading all the registers (this will 
clear the RX data ready by reading the RX register) and then turning it 
on again.
Q: why has this only recently started to be a problem.
I can confirm that RiscPC machines use early revision. Mine is Revision 2 
but I have seen revision 1 in RPC's

I am resturucturing the combo chip driver so that a pioc device is 
attached and probes the 37C655. Then serial, parallel, ide and floppy will
be attached as children of the combo chip.
The prototype driver for this is where I can get the chip revision from.
ID and revision can be obtained by putting the chip into config mode and 
reading the ID register).

My SMC data sheet does not describe any bugs in the chips. I'll try and 
get all the note on revisions from SMC.

Anyway this bug certain fits with the behaviour I have observed so 
hopefully my fix is actually the correct way to handle this.

Cheers,
				Mark


Mark Brinicombe				amb@physig.ph.kcl.ac.uk
Research Associate			http://www.ph.kcl.ac.uk/~amb/
Department of Physics			tel: 0171 873 2894
King's College London			fax: 0171 873 2716