NetMos 9865 || 6 x serial port PCI card || What is /lib/modules/$(uname -r)/build ?
 

I have the card SD-PCI15008:
http://www.syba.com/index.php?contro...on=Info&Id=819

It's a serial port PCI card with 6 ports. As you can see on the website, the manufacturer says that it's compatible with Linux.
Looking at the card in more detail, I see a chip with the following written on it:
MOSCHIP SEMICONDUCTOR MCS9865IV-AA

Here's some info on my system.
$uname -srvmo says the following:
My system is an up-to-date Debian Lenny installed on a Dell Vostro 220 desktop.

If I compare the output of lspci with and without the card inserted, then with the card inserted I get the following three extra lines:
lspci -v for these three lines with the card installed is:
I don't see any mention of anything similar using lshw.

According to lsmod, the same kernel modules are present with or without the card installed. There are no extra ones when the card is there.

Now I'm not all that well experienced with communicating with serial ports, but I'm just doing a few basic tests like looking for /dev/ttyS*. I get the following:
regardless of whether the card is installed. There's supposed to be at least six of them. So I'm assuming from this that there is no module getting loaded for this card.

So this gives two options. I can either look for a driver that Debian might magically provide by apt-get/aptitude or I could install the driver from source that comes on a CD with the card.

Having had no luck looking with Debian's "apt-cache search" for packages with names that I was trying to guess, I'm planning to install the driver from the source code. The card comes with a CD that has some source code in it and some instructions.

In this CD that came with the card, there's the following statement:
"This driver is currently developed and tested on 2.6.11 linux kernel and above." That can be interpreted as good or also perhaps bad considering 2.6.11 isn't really all that recent, but I'm heartened slightly by the fact that the card is very recently purchased.

Anyway, on the CD there's a directory with all the code needed to install this driver. The instructions are really straightforward. All you have to do is use "make" and then "insmod" and then you're done, or alternatively use "make install".

In the Makefile, it defines a directory:
and later uses that directory:
This directory, which would be /lib/modules/2.6.26-2-686/build, does not exist on my system. Would it exist if I just had the right thing installed? I'm not used to compiling drivers, so it's possible that I just haven't got the right stuff installed to allow for this code to compile.

Do other people have /lib/modules/$(uname -r)/build ?

If there's any suggestions on other information that I can provide, or on how to proceed, then they would be much appreciated.
Thanks.

I found the following to be interesting:
http://linux.derkeiler.com/Mailing-L.../msg01241.html
Just use "apt-file search" and this tells you how to get a certain file installed on your system. Pretty handy. Hopefully this will give me what I need to be able to proceed.

EDIT
====

So I was able to get it to work. In the end it wasn't too bad once I installed the Debian package linux-headers-2.6.26-2-686, which is the package that creates the directory /lib/modules/$(uname -r)/build

If you are using an rpm-based distro then you can use "yum provides" instead of "apt-file search", as shown here:
https://help.ubuntu.com/community/Sw...LinuxAndFedora

If anyone else is going to use this card, then there are a few things worth mentioning.

1) Hang on to the CD that comes with the card. The driver software comes on the CD, and if you want it to work, then chances are good you'll need the driver. If you lost the CD, then supposedly it's also available at www.moschip.com.

2) The CD's got a bunch of other drivers on it. On my CD, the driver was located at
cd-root-directory/Moschip/MCS9865/Linux/
So just look for files with "9865" in their name and you should find it. Then in that directory are files like mcs9865.c and several others along with a readme and a .doc that explain how to go about installing the driver.

3) So just follow the directions.

4) When running 'make', I came across one issue. I got an error saying that SA_SHIRQ is undeclared.

Fortunately for me, I came across the explanation at http://linmodems.technion.ac.il/biga.../msg00710.html which prompted me to rename SA_SHIRQ in mcs9865.c to IRQF_SHARED. Once I did that, everything compiled. The output of the make command looked like:

5) When doing 'make install', apparently you don't have to worry about the following:
At first I was worried about that, but mine works so I'm no longer worried.

6) Then there will be ttyS0, ttyS1, ttyS2, ttyS3, ttyD0, ttyD1. ttyD? previously did not exist, and ttyS? previously did not work.
On mine, ttyS0,1,2,3 are labeled as cables 3,4,5,6 respectively while ttyD0,1 are labeled as cables 1,2 respectively.

7) Get a null modem cable and hook up one end to the cable corresponding to /dev/ttyS0, then hook another up to the cable corresponding to /dev/ttyS1. You can get null modem mini adapters that would be suitable for this.
http://www.winfordeng.com/products/mgcnm.php

Once you've got them connected with a null modem adapter, then do the following.
In a shell type: #cat > /dev/ttyS1
In a root shell type : #echo "hello" > /dev/ttyS0

If all is well then you might see "hello" appear from stdout of the shell that's catting /dev/ttyS1.

A better way to test it is probably to use the command cu which comes in packages with names like uucp. There's also the command minicom.

I have the same board and have followed your instructions, but I'm only getting the first two serial ports (D1 and D2) to work. The others don't work for me.

What's your output for the following?

root@ubuntu:/home/mh/Desktop/MCS9865_Linux# setserial -g /dev/tty[SD]*
/dev/ttyD0, UART: 16550A, Port: 0xe800, IRQ: 20
/dev/ttyD1, UART: 16550A, Port: 0xe400, IRQ: 21
/dev/ttyS0, UART: 16550A, Port: 0xe000, IRQ: 11
/dev/ttyS1, UART: 16550A, Port: 0xd800, IRQ: 11
/dev/ttyS2, UART: 16550A, Port: 0xd400, IRQ: 11
/dev/ttyS3, UART: 16550A, Port: 0xd000, IRQ: 11

I also noticed that in the output of "lshw", the third portion defining those ports seems wrong. Is yours UNCLAIMED, too?

*-communication:0
description: Serial controller
product: PCI 9865 Multi-I/O Controller
vendor: NetMos Technology
physical id: 5
bus info: pci@0000:03:05.0
version: 00
width: 32 bits
clock: 33MHz
capabilities: pm bus_master cap_list
configuration: driver=mcs9865-serial latency=64 module=mcs9865
*-communication:1
description: Serial controller
product: PCI 9865 Multi-I/O Controller
vendor: NetMos Technology
physical id: 5.1
bus info: pci@0000:03:05.1
version: 00
width: 32 bits
clock: 33MHz
capabilities: pm bus_master cap_list
configuration: driver=mcs9865-serial latency=64 module=mcs9865
*-communication:2 UNCLAIMED
description: Communication controller
product: PCI 9865 Multi-I/O Controller
vendor: NetMos Technology
physical id: 5.2
bus info: pci@0000:03:05.2
version: 00
width: 32 bits

From "lspci -v":

03:05.0 Serial controller: NetMos Technology PCI 9865 Multi-I/O Controller (prog-if 02)
Subsystem: Device a000:1000
Flags: bus master, medium devsel, latency 64, IRQ 20
I/O ports at e800 [size=8]
Memory at febff000 (32-bit, non-prefetchable) [size=4K]
Memory at febfe000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [48] Power Management version 2
Kernel driver in use: mcs9865-serial

03:05.1 Serial controller: NetMos Technology PCI 9865 Multi-I/O Controller (prog-if 02)
Subsystem: Device a000:1000
Flags: bus master, medium devsel, latency 64, IRQ 21
I/O ports at e400 [size=8]
Memory at febfd000 (32-bit, non-prefetchable) [size=4K]
Memory at febfc000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [48] Power Management version 2
Kernel driver in use: mcs9865-serial

03:05.2 Communication controller: NetMos Technology PCI 9865 Multi-I/O Controller
Subsystem: Device a000:3004
Flags: bus master, medium devsel, latency 64, IRQ 11
I/O ports at e000 [size=8]
I/O ports at d800 [size=8]
I/O ports at d400 [size=8]
I/O ports at d000 [size=8]
Memory at febfb000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [48] Power Management version 2

I'll be happy to see if I can help you out.

Since getting the first one working, I actually tried to use a second in the same computer, to see if I could get 12 serial ports going at once. I was able to get /dev/ttyD2 and /dev/ttyD3 going by just inserting the second card, but that's it so far. It might just be that the driver wasn't designed for two cards, not sure.

Anyway, that's neither here nor there for your issue.
The second card isn't in there right now so we don't have that distraction.

Here's the output you were wondering about:
I don't see anything about unclaimed in lshw nor did I ever come across that.

Let me know if there's anything else I can provide you with.

I don't use Debian, however both posters to this thread may find some useful information in another thread I took part in a while back. It deals with the file /etc/serial.conf (that's what it's called on my Slackware system; it *could* have a different name on your systems, but I think it should be very similar or the same).

Anyhow, that file allows you to configure all of your serial ports specifically, for which tty**, which IRQ, which address registers, etc. Note that possibly the `setserial` command can also/probably set some/all these items for you, so it may come down to personal preference. Anyhow, here are a link or two, just in case it helps:

This post Here. And This Thread Here.

PS - @ Chadwick -- have you considered adding your serial card device to LQ's HCL? If it isn't there yet, that'd be a good addition :)

And also -- the /lib/modules/`uname -r`/build folder exists on everyone's Linux system, if they have the kernel-source-code installed and have built their kernel from that source-code. I believe it is usually actually a symlink to the kernel source folder. Some systems, like maybe Debian (I'm not familiar with that) may arrange for this folder to me "created" during the installation of the OS, but generally, it's created when you build your kernel.

Sasha

With the driver installed, here's what I see using lspci -v
What commands specifically are you using to install the driver?

Do you just use
or maybe better

id628, I assume the last two lines of your lspci -v were probably just cut off, or were the last two lines that show up in mine actually not there in yours?

Thanks GrapefruiTgirl. Hopefully I'll have some time to look into this at some point. As it is I might or might not need the other four serial ports but would find it interesting to get them to work.


This did cross my mind but I never did it. Thanks for the suggestion, I'll give it a shot when I get a moment.

It magically appears when you install the relevant package :).

just got the NetMos SY-PCI5004 (MCS9865 chip)
 

downloaded the driver from here: http://www.iocrest.com/products.php?...379e6e46964857

had to patch up mcs9865.c as stated (thanks everyone for posting information), so here are some notes on what I did:

Change into the source folder and do something like:

then as root

haven't installed yet, still testing stability but should be safe to make install

<patched removed as it contained carriage returns, check post 20 instead>

(restating for opensuse)
as far as /lib/modules/$(uname -r)/build, on opensuse 11.2 it is a symlink:

$ ls -l /lib/modules/$(uname -r)/build
lrwxrwxrwx 1 root root 46 2009-11-19 21:18 /lib/modules/2.6.31.5-0.1-desktop/build -> /usr/src/linux-2.6.31.5-0.1-obj/x86_64/desktop

This symlink was broken until I installed kernel-desktop-devel (which also installed kernel-source and linux-kernel-headers)

had to change more for 2.6.32-rc5. i have done a short test and it worked fine

also this card worked with xen hypervisor, referring to earlier dmesg |grep ttyD output I added the following on the xen grub line
com1=19200,8n1,0xe480,17 console=com1

I am having a real headache trying to install a MosChip MC9865 6 port serial card in my openSUSE 11.2 machine.

I'm pretty new to linux, so I'm trying to understand what I am missing.

We'll start backwards..

When I try and MAKE (using the files off of the mini-cd that came with the card) here is the output:
All you smart people probably already know the problem.

I've installed the Kernel Dev-Lev files in YAST. I also rebooted the computer.

Here is my dmsg grep:

And here is my "lspci -v" - cropped just to show the ports I am trying to install, to at least show the OS knows the boards are there and talking to the motherboard.


Thanks for the help.. I've been working on this for the last 5 hours!

The make output shows that the source code hasn't been patched yet. Try the patch in post #9.

Hi Liquid Squelch,

I don't remember ever coming across the error that you see when you try to compile the driver. I don't know offhand if the struct uart_info is defined in a header file that's supposed to come with your OS or if it's defined in the code that comes on the cd. Chances are good that it's something that comes with your OS. Perhaps the names of the member variables of the struct uart_info depend on the version of a certain set of files. If that's the case, then we would have to figure out what versions of these files you need to use. I am not a hardware expert, and in my case I was probably just lucky that it worked. So it might be a good idea to start out by finding out where struct uart_info is defined.

EDIT: I hadn't yet seen dblade's reply where he says his patch will fix it. Probably a better idea to start with that then.

So did anyone succed in using all 6 ports of the controller?I am having trouble getting past the 2 on the board.

The suspicious part in dmest is this
Any help greatly appreciated.

It seems at least two of us have had success at that. I've succeeded in getting six to work for one card and two for a second card. What's your procedure for installing the driver? What kernel are you using? Have you also tried looking at output of lspci, setserial, lshw to see if that gives any clues?

I did actually get more than 2 ports working :).
I pathed the 1.06 version,since the other one did not load the mcs9865-isa module corectly and I finaly have at least 4 ports working (did not try the other 2).
2.6.32-3 debian vanilla.

Thanks all for the help, but after months of putting this off, I'm back at it again..

When I try and Patch, this is the error I get:

This fails when I try and patch as user, and SU.

You guys got one error in addition to mine. I didn't have any issues with struct uart_info having its members renamed. Thanks dblade for posting your patch about that.

Liquid_Squelch, if the patch isn't working then you can just edit the file by hand. It seems there are only 4 lines that you need to change. Try the following:

Back up mcs9865.c:
Open mcs9865.c with a text editor (e.g. emacs) and

1. replace the three occurrences of:
   Code:

   ---

   up->port.info->tty

   ---

   (which are on lines on lines 622, 852 and 957 in my versions of the file) with:
   Code:

   ---

   up->port.info->port.tty

   ---

2. replace the occurrence of:
   Code:

   ---

   SA_SHIRQ

   ---

   (which is on line 2068 in my version of the file) with:
   Code:

   ---

   IRQF_SHARED

   ---

Not sure if you're used to using text editors in GNU/Linux (since you say you're new to Linux). If not, then the search command key binding in emacs is <ctrl>-s and the search-and-replace binding is <alt>-<shift>-%

Once you've taken care of that, try doing make again.

assuming you are on 2.6.31.x with that patch

looks like the patch file has carriage returns (^M) in it. I have no idea why, but you could use:

dos2unix
-OR-
vi editor, command :1,$s/<ctrl-v><ctrl-m>//g
-OR-
sed -i 's/<ctrl-v><ctrl-m>//g' patch.txt

to remove them.

(where <ctrl-v> and <ctrl-m> mean to actually press those keys)

EDIT: FYI

I had to see what was going on with this. Even after I removed the ^M 's from the patch (new file attached) it wouldn't apply until I removed the ^M's from mcs9865.c file. They have no business being in there but apparently the driver was packaged up on windows...

Thanks for the help all.... i am almost there!

I was finally able to make and install. I manually made the changes, and then removed all of the carriage returns.. I also performed a chmod to all of the files to make sure there were no issue..


Now, my problem, is I can 'cat' some of the ports..

I can see the ports listed, and I am assuming ttyS2 - S7 are the new ports.
# setserial -g /dev/tty[SD]*
/dev/ttyD0, UART: 16550A, Port: 0xdcf8, IRQ: 17
/dev/ttyD1, UART: 16550A, Port: 0xdcf0, IRQ: 18
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: unknown, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4
/dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3
/dev/ttyS4, UART: 16550A, Port: 0xdce8, IRQ: 19
/dev/ttyS5, UART: 16550A, Port: 0xdcd8, IRQ: 19
/dev/ttyS6, UART: 16550A, Port: 0xdcc8, IRQ: 19
/dev/ttyS7, UART: 16550A, Port: 0xdcb8, IRQ: 19


When I try and 'cat' the ports ttyS2, ttyS3, ttyD0, or ttyD1, I receive an error:

# cat /dev/ttyS2
cat: /dev/ttyS2: Input/output error

This tells me that the piggy back com ports are working. It is the physical 2 on board serial cards are UART unknown. I tried setting UART to 16550A but that still gave me the error - so I change the IRQ to 19.. Still no go. Any pointers to get the last 2 serial cards up and running?

THANK YOU AGAIN for all who have helped me out.. we're at the home stretch!

also on 33 kernel taked errors:
1)"error: 'struct uart_port' has no member named 'info'"
2)"error: 'struct uart_state' has no member named 'delta_msr_wait'"
solutions:
1) replace "port.info" to "port.state"
2) replace "delta_msr_wait" to "port.delta_msr_wait"

full patched version of mcs9865.c at pastebin.com/RaRqpF15

arkhnchul, sounds similar to the changes in the patch attached to post #11.

If you wanted to take the time to create a stand alone/complete patch file for 2.6.33, just create a copy of the original source file [1] before any editing (calling it something like mcs9865.c.orig) and after doing all of the editing changes to get it work, do a "diff -u msc9865.c.orig mcs9865.c > mcs9865_patch2.6.33.x.txt" (or similar).

[1] If you do decide to do it, also make sure that you get rid of the carriage returns (^M) in the original source file first. That caused issues with the patches I had posted as recently discussed.

Thanks.

Driver 1.0.0.6 with no carriage returns can be found here: http://filebin.ca/prdjxz/MCS9865_V1.0.0.6_noCR.tgz

So I tried to use the patch that was given in message #9. It failed with the following output:

w72efx@bm-server2010:~/mostek_serial_port/MCS9865_Linux/MCS9865_V1.0.0.6$ sudo !!
sudo patch -p0 < /home/w72efx/Downloads/mcs9865_try1_patch.txt
[sudo] password for w72efx:
(Stripping trailing CRs from patch.)
patching file mcs9865.c
Hunk #1 FAILED at 619.
Hunk #2 FAILED at 849.
Hunk #3 FAILED at 954.
Hunk #4 FAILED at 2065.
4 out of 4 hunks FAILED -- saving rejects to file mcs9865.c.rej
w72efx@bm-server2010:~/mostek_serial_port/MCS9865_Linux/MCS9865_V1.0.0.6$

What went wrong?

Usually when a patch completely fails, there are one or more of several reasons:

1 -- the patch is for a significantly different version of the source code (or the source code has changed since the patch was made).
2 -- you aren't inside the correct directory when you apply the patch.
4 -- patch is in the wrong format to begin with.
3 -- some other reason.

I find it odd that it says "Stripping trailing CRs from patch." - I haven't seen that in the past.

Maybe, assuming the problem is not #1 or #2 or #4 reason I suggested for the failure, try increasing the `fuzz factor` for patch, it might succeed? Or it might not..
Read the `patch` manpage for info about `fuzz factor`.

post 18 is the same problem and I've provided a solution in post 20. I've also removed the patch in post #9. You didn't say what kernel you are on, but maybe try the patch in post 20.

For a kernel .32 and newer I'd try out the patch in post #11.

Wow, fast responses. Thanks! I'll try dblade's ideas first and then if I have to I'll move on to grapefruitgirl's ideas. I'll let everyone know what happens.

Sorry to resurrect an old thread but I have this same problem. My card is a Syba SY-PCI15001 6-port with the MOSCHIP 9865. I've acquired three drivers for it. The oldest was supplied with the CD that came with the card. More recent is the one I downloaded from Syba's website.

http://www.sybausa.com/productInfo.php?iid=602

The newest version I downloaded from MOSCHIP website.

http://www.moschip.com/mcs9865_downloads.php

It looked as if this latest version from MOSCHIP would not require patching. The readme says it supports kernels 2.6.22 to 2.6.33. I am using LinuxMCE based upon Kubuntu 8.10 with the 2.6.27.17 kernel so I thought I would be OK. I looked at the patch and saw that it was just making a few syntax modifications to match kernel updates. Looking at the most recent MCS9865.c file, it does check for the kernel version in order to supply the correct syntax. Here is an example:

However when I try to install I get errors.

Does anyone know what this means or how to get rid of it?
"warning: comparison of distinct pointer types lacks a cast"

John

This card is working now for Debian (Ubuntu, Kubuntu). Here is the procedure:

1. download MCS9865_V1.0.0.11. driver from MOSCHIP and extract
2. open terminal and change to the newly created directory
3. "make" (no sudo required)
4. copy mcs9865.ko and mcs9865-isa.ko to /lib/modules/pick-your-kernel-version/kernel/drivers/serial
5. edit /etc/modules and add a line "mcs9865"
6. "depmod -a"
7. reboot

The only warning "comparison of distinct pointer types lacks a cast" during make but that is not a show stopper.

I did get all ports on both of my cards to work so I thought I'd mention that. I followed GrapefruiTgirl's instructions and it was pretty easy. Thanks GrapefruiTgirl for your help. My kernel is 2.6.25-14.fc9.i686 (it's no longer a Debian one as stated in a previous post) and I'm using legacy grub (GNU GRUB 0.97). Note this is quite an old kernel and an old version of grub. I just needed to include 8250.nr_uarts=8 in my kernel boot line. Note that nr_uarts=8 doesn't seem to work.

So it's just a matter of telling the kernel at boot time how many serial ports to allow for, and then in my case I now have the following serial port devices working: /dev/ttyD0, /dev/ttyD1, /dev/ttyD2, /dev/ttyD3, /dev/ttyS0, /dev/ttyS1, /dev/ttyS2, /dev/ttyS3, /dev/ttyS4, /dev/ttyS5, /dev/ttyS6, /dev/ttyS7. It's interesting you only need to specify 8250.nr_uarts=8 for these cards even though there are actually 12 ports in total that are created. I'm thinking perhaps the driver takes care of the remaining 4 by creating the /dev/ttyD[1-4] devices.