Estou com problemas ao tentar usar quatro das seis portas seriais da minha placa-mãe.
A situação é:
Tenho 6 portas seriais disponíveis - ttyS0 a ttyS5 - das quais 0 é uma porta RS232 na borda da placa-mãe e as outras 5 são cabeçalhos de série diretamente na placa. Na configuração padrão do BIOS, eles são mapeados da seguinte forma:
- ttyS0: IRQ 4
- ttyS1: IRQ 3
- ttyS2: IRQ 10
- ttyS3: IRQ 10
- ttyS4: IRQ 10
- ttyS5: IRQ 10
O Linux relata corretamente isso usando o dmesg para verificar como eles são configurados inicialmente, e os comandos setserial podem ser usados para alterar esses valores. Eu escrevi estes em um script que eu corro na inicialização para que eu possa configurar os IRQs, velocidades e algumas outras configurações automaticamente durante a inicialização. Eu não posso mudar a maioria destes no BIOS como para 2-5 Eu só tenho a opção de usar o IRQ 10.
No entanto, usando um script Python para transferir 100.000 caracteres de uma porta para outra (ou de um PC externo) nessa configuração, as quatro portas que compartilham o IRQ 10 não funcionam. Isso ocorre apesar do compartilhamento de IRQ estar habilitado no kernel e do chip GPIO presente (Fintek F81866A) suportando isso. Normalmente, o programa python fica bloqueado na linha aberta da porta (independentemente da leitura / gravação). O ttyS0 e o ttyS1 funcionam corretamente usando os mesmos scripts e, de fato, qualquer teste que menciono abaixo usa o mesmo código. Um script abre uma porta e aguarda informações enquanto o outro gera 100.000 caracteres aleatórios e envia isso. Há uma verificação básica de que as informações são as mesmas em ambas as extremidades.
Eu consigo fazer com que funcionem ao trocá-los para IRQ 0 (modo polled), mas a velocidade e a estabilidade não são adequadas para a aplicação. Se eu mudar qualquer um dos 2-5 no IRQ e ligá-los ao ttyS0, eu obtenho a funcionalidade normal quando compartilho um IRQ (4), mas quando o ttyS0 não está ativo (ou seja, do meu computador externo para o ttyS2-5) eles exibem o mesmo comportamento que quando configurados para IRQ 10.
O único outro teste que executei foi o de desabilitar as últimas três portas no BIOS, então o ttyS2 era o único no IRQ 10, no qual ele operava perfeitamente normalmente rodando na mesma velocidade que o ttyS0 e o 1. Para mim, isso implica que o problema é especificamente com as interrupções compartilhadas, mas quando tentei mover as portas para IRQs que estavam desocupadas (11 e 12, se bem me lembro), não houve melhora.
Especificamente observando as interrupções quando o script python está executando o IRQ 3 e o IRQ 4 se comportam como eu esperaria com interrupções ocorrendo conforme necessário, no entanto, se eu tentar chamar uma das outras portas definidas como IRQ 10 não vejo nenhum muda além de uma inicial quando tento abrir a porta. Quando apenas uma porta usa IRQ 10, as interrupções atuam como em 3 e 4.
Desci algumas rotas investigando por que esse poderia ser o caso, e estou ficando mais convencido de que o chip do Fintek está causando um problema. Nas minhas configurações e drivers do Kernel (3.19) eu posso encontrar referências para produtos Fintek mais antigos, mas não este. A outra razão que eu acho que o chip é o problema é que eu tenho um cabeçalho GPIO na placa-mãe que também está neste estado estranho de semi-funcionalidade. Eu posso ver que está lá e pegar corretamente o ID, mas não acessá-lo ou usá-lo além disso.
Quais opções eu tenho para corrigir este problema, e é provável que exista algum problema de compatibilidade com o Fintek IO Controller? No momento, estou instalando uma versão mais recente do kernel para ver se há suporte interno para o F81866A, e não tenho experiência em tentar escrever algo para orientar isso sozinho, se é isso que é necessário.