Kernel 2.6 serial driver problem

[zinfo]

Hi, we have some problem with a particular version of a ns16550. We can receive caracter correctly, but when we send some (stream of 40), after the 17th caracter, we don't receive the 18th and over. We can repeat the test, and we still receive only the first 17 caracters.

About the hardware :
486DX
Super I/O Chip : F82C735, Enhanced I/O peripheral controler made by Chips, which include 2 ns16550

Linux detect the serial port as TI16750 :
ttyS0 at 0x03f8 (irq = 4) is a TI16750
ttyS1 at 0x02f8 (irq = 3) is a TI16750

We have used setserial to tell the kernel to use routine for :
16550
16550A
16450

But we still have the same problem.

It work with a 2.4.18 kernel but not with a 2.6.24

If someone have idea they will be welcome!

Thank you.

[dilbert]

Is it a real 2.6 driver or runs a 2.4 driver with a 2.6 kernel?

If it's a genuine 2.6 driver, does it run fine elsewhere?
If yes, is there something configurable and maybe not configured properly?

If it's a 2.4 driver then it might be adapted to run on 2.6. Similar drivers might a clue, then.

[dxqcanada]

What is the 17th and 18th character ?

[zinfo]

Answer for Dilbert,

It's a real 2.6 driver and it work on other machines but they have different chip set.

Our 2.4 solution is working well on the same machine. But the 2.6 kernel is not.

[zinfo]

For dxqcanada,

there is no data after the 17th character. The string we send is (40 bytes) :
1234567890123456789012345678901234567890

[dilbert]

Looks to me that someone ported the driver from 2.4 to 2.6 but didn't take care of your chipset.

Maybe you figure out the differences. It could be the length of a buffer or something like that.

There are substantial changes between 2.4 and 2.6 drivers but possibly you can figure out what's crucial for you by searching the Web for similar problem or a comparison of source code could already give some obvious clues.

Another possibility is a proprietary driver. Some companies add a driver with their products (on CD or downloadable) that modifies an open source driver and leaves that useless for other products.

I remember once having produced an ASIX driver with the original source code plus twice the changed code from two vendors.
Thus having three chunks of almost the same code in one driver, accessing it via different vendor/product IDs. Ugly thing, but was for internal purposes only.