Thanks Bjorn.. you did it again! The SC400 bug you mention below was indeed
the problem. I got around it in the serial driver if anyone's interested.
--andy
-----Original Message-----
From: Bjorn Eriksson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 13, 1999 11:37 AM
To: '[EMAIL PROTECTED]'
Cc: 'Andy Waddell'
Subject: SV: AMD SC400 evaluation board, DiskOnChip 2000 and Kernel
2.0.35won't tango.
>Excellent!! I just tried it and it does indeed work. I'm seeing something
>else strange that maybe somebody can explain. Early in the boot I
configure
>all of the serial ports to the following settings (using CSC registers):
>
>SC400 internal - 0x3f8, IRQ4
>external 1 (middle) - 0x2f8, IRQ3
>external 2 (right) - 0x3e8, IRQ5
>
>In my initialization script I use "setserial" to configure these just for
>good measure, and then run getty's on each. The two external ports work
>flawlessly, but the internal one has a very strange behavior. It will ever
>so slowly spit out 16 characters at a time. At first I assumed that Linux
>wasn't seeing the interrupts from the UART, but when I looked at
>/proc/interrupts, I saw one interrupt (on IRQ4) for each 16 character
chunk.
>Also, I found that if I type a charater on the attached terminal I
>immediately get a couple interrupts and another 16 characters of output. I
>can't think of an explanation for this except that the BIOS is configuring
>some strage CSC combo that is causing problems. I've looked at the SC400
>user's guide but can't see anything I'm doing wrong.
Hmmm, that triggers a synapse. I wrote down this a couple of months ago:
The problem is that the UART_LSR_THRE bit is delayed one bit
clock after the interrupt line is asserted, i.e. if the serial
port is running at 1200 bps, and the tranmitter becomes empty
and causes an interupt, the interrupt is signalled about a
millisecond (1/1200 second) _before_ the THRE bit is set.
Sounds applicable. Sorry don't where I got it from. Usenet problably.
//Björn Eriksson
