I'm having problems trying to make use of four out of six serial ports on my motherboard.
The situation is:
I have 6 serial ports available - ttyS0 to ttyS5 - of which 0 is a RS232 port on the edge of the motherboard and the other 5 are serial headers directly on the board. In the standard BIOS configuration these are mapped as follows:
- ttyS0: IRQ 4
- ttyS1: IRQ 3
- ttyS2: IRQ 10
- ttyS3: IRQ 10
- ttyS4: IRQ 10
- ttyS5: IRQ 10
Linux correctly reports this using dmesg to check how they are initially set up, and setserial commands can be used to change these values. I've written these into a script I run at startup so I can configure the IRQs, speeds, and a couple of other settings automatically during the boot. I cannot change most of these in the BIOS as for 2-5 I only have the option of using IRQ 10.
However using a Python script to transfer 100,000 characters from one port to another (or from an external PC) in that configuration the four ports sharing IRQ 10 do not function. This is in spite of IRQ sharing being enabled in the kernel and the GPIO Chip present (Fintek F81866A) supporting this. Typically the python program becomes locked at the port open line (regardless of read/write). ttyS0 and ttyS1 function correctly using the same scripts and indeed any tests I mention below use the same code. One script opens a port and waits for information while the other generates 100,000 random characters and sends this. There's a basic check that the information is the same both ends.
I can get them to function when switching them to IRQ 0 (polled mode) but the speed and stability there is not suitable for the application. If I change any of 2-5 onto IRQ and connection these to ttyS0 I then get normal functionality when sharing an IRQ (4), however when ttyS0 is not active (i.e. I'm going from my external computer to ttyS2-5) they exhibit the same behavior as they do when set to IRQ 10.
The only other test I have run which was of note was disabling the last three ports in the BIOS so ttyS2 was the only one on IRQ 10, at which point it operated perfectly normally running at the same speed as ttyS0 and 1. To me this implies that the problem is specifically with the shared interrupts, but when I tried moving the ports onto IRQs which were otherwise unoccupied (11 and 12 if I remember correctly) there was no improvement.
Specifically watching the Interrupts when the python script is running IRQ 3 and IRQ 4 behave as I would expect with interrupts occurring as needed, however if I attempt to call one of the other ports set to IRQ 10 I don't see any changes beyond an initial one when I attempt to open the port. When only one port uses IRQ 10 the interrupts act as they do on 3 and 4.
I've gone down a few routes investigating why this might be the case, and I'm becoming more convinced that the Fintek chip is a causing a problem. In my Kernel (3.19) settings and drivers I can find reference to older Fintek products but not this one. The other reason I think the chip is the problem is that I have a GPIO header on the motherboard which is also in this odd state of semi-functionality. I can see that it is there and correctly pick up it's ID but not actually access it or use it beyond this.
What options do I have for correcting this problem, and is it likely that there is some compatibility problem with the Fintek IO Controller? I'm currently installing a newer kernel version to see if that has built-in support for the F81866A, and I have no experience in attempting to write something to drive this myself if that is what is required.