Find the answer to your Linux question:
Results 1 to 6 of 6
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 ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Mar 2009
    Posts
    9

    Kernel 2.6 serial driver problem


    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.

  2. #2
    Linux Newbie dilbert's Avatar
    Join Date
    Sep 2006
    Location
    Yorkshire, GB
    Posts
    237
    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.
    Bus Error: Passengers dumped. Hech gap yo'q.

  3. #3
    Linux User dxqcanada's Avatar
    Join Date
    Sep 2006
    Location
    Canada
    Posts
    259
    What is the 17th and 18th character ?



    Men occasionally stumble over the truth,
    but most of them pick themselves up
    and hurry off as if nothing had happened.

    Winston Churchill


    ... then the Unix-Gods created "man" ...

  4. #4
    Just Joined!
    Join Date
    Mar 2009
    Posts
    9
    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.

  5. #5
    Just Joined!
    Join Date
    Mar 2009
    Posts
    9
    For dxqcanada,

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

  6. #6
    Linux Newbie dilbert's Avatar
    Join Date
    Sep 2006
    Location
    Yorkshire, GB
    Posts
    237
    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.
    Bus Error: Passengers dumped. Hech gap yo'q.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •