I have a problem when trying to use two of the serial cards known as
MOXA C104H/PCI.
When only using one, everything works like a charm, but when
an attempt is made to access a serial port on the second card,
I get a NULL pointer dereference.
This is the relevant output from dmesg:
MOXA Smartio family driver version 1.2
Tty devices major number = 174, callout devices major number = 175
Found MOXA C104H/PCI series board(BusNo=0,DevNo=10)
The relevant stuff from /proc/pci:
Bus 0, device 10, function 0:
Serial controller: Moxa Technologies Co Ltd Smartio C104H/PCI (rev 2).
IRQ 10.
I/O at 0xa800 [0xa87f].
I/O at 0xa400 [0xa43f].
I/O at 0xa000 [0xa00f].
Bus 0, device 11, function 0:
Serial controller: Moxa Technologies Co Ltd Smartio C104H/PCI (#2) (rev 2).
IRQ 11.
I/O at 0x9800 [0x987f].
I/O at 0x9400 [0x943f].
I/O at 0x9000 [0x900f].
And here is the decoded oops:
ksymoops 2.4.1 on i686 2.4.16. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.16/ (default)
-m /boot/System.map-2.4.16 (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Nov 24 16:49:35 cola kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000024
Nov 24 16:49:35 cola kernel: c01946e3
Nov 24 16:49:35 cola kernel: *pde = 00000000
Nov 24 16:49:35 cola kernel: Oops: 0000
Nov 24 16:49:35 cola kernel: CPU: 1
Nov 24 16:49:35 cola kernel: EIP: 0010:[mxser_change_speed+15/1760] Not tainted
Nov 24 16:49:35 cola kernel: EFLAGS: 00010282
Nov 24 16:49:35 cola kernel: eax: 00000000 ebx: d48bfee8 ecx: 00000000 edx: 00000001
Nov 24 16:49:35 cola kernel: esi: 00000000 edi: d4caabf0 ebp: d4caa000 esp: d48bfea0
Nov 24 16:49:35 cola kernel: ds: 0018 es: 0018 ss: 0018
Nov 24 16:49:35 cola kernel: Process minicom (pid: 678, stackpage=d48bf000)
Nov 24 16:49:35 cola kernel: Stack: d4caa000 d48bfee8 d4caabf0 d4caa000 00000000 c02e5280 c0193f8b 00000000
Nov 24 16:49:35 cola kernel: d48bfee8 d48bfee8 00000002 c0180b30 d4caa000 d48bfee8 bffff3f8 bffff41c
Nov 24 16:49:35 cola kernel: d48bff54 d48bff30 00000500 00000005 00000cbd 00008a3b 7f1c0300 01000415
Nov 24 16:49:35 cola kernel: Call Trace: [mxser_set_termios+51/128] [change_termios+368/396] [set_termios+383/396] [n_tty_ioctl+185/1024] [tty_ioctl+891/912]
Nov 24 16:49:35 cola kernel: Code: 8b 46 24 85 c0 74 17 8b 80 00 01 00 00 85 c0 74 0d 8b 40 08
Using defaults from ksymoops -t elf32-i386 -a i386
Code; 00000000 Before first symbol
00000000 <_EIP>:
Code; 00000000 Before first symbol
0: 8b 46 24 mov 0x24(%esi),%eax
Code; 00000003 Before first symbol
3: 85 c0 test %eax,%eax
Code; 00000005 Before first symbol
5: 74 17 je 1e <_EIP+0x1e> 0000001e Before first symbol
Code; 00000007 Before first symbol
7: 8b 80 00 01 00 00 mov 0x100(%eax),%eax
Code; 0000000d Before first symbol
d: 85 c0 test %eax,%eax
Code; 0000000f Before first symbol
f: 74 0d je 1e <_EIP+0x1e> 0000001e Before first symbol
Code; 00000011 Before first symbol
11: 8b 40 08 mov 0x8(%eax),%eax
The machine is an SMP box, but I don't think, that's the cause, as the oops happens
immediately every time.
If there is any other info I need to provide, I'll be happy to do so.
Thanks in advance.
--
Best regards
Christian Laursen
Christian Laursen <[email protected]> writes:
> I have a problem when trying to use two of the serial cards known as
> MOXA C104H/PCI.
>
> When only using one, everything works like a charm, but when
> an attempt is made to access a serial port on the second card,
> I get a NULL pointer dereference.
>
I forgot information about my versions of things in the other post,
here we go:
[xi@borg /usr/src/linux/scripts]$ ./ver_linux [19:22]
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux borg 2.4.16 #1 SMP Thu Dec 6 22:23:25 CET 2001 i686 unknown
Gnu C 2.95.3
Gnu make 3.79.1
binutils 2.11.90.0.29
util-linux 2.11i
mount 2.11i
modutils 2.4.8
e2fsprogs 1.24a
reiserfsprogs 3.x.0k-pre9
pcmcia-cs 3.1.28
PPP 2.4.1
isdn4k-utils 3.1pre2
Linux C Library x 1 root root 1384168 Sep 20 05:52 /lib/libc.so.6
Dynamic linker (ldd) 2.2.4
Procps 2.0.7
Net-tools 1.60
Kbd 1.04
Sh-utils 2.0
Modules Loaded nfsd lockd sunrpc 3c59x
--
Med venlig hilsen
Christian Laursen
On 10 Dec 2001 18:53:48 +0100
Christian Laursen <[email protected]> wrote:
> I have a problem when trying to use two of the serial cards known as
> MOXA C104H/PCI.
>
> When only using one, everything works like a charm, but when
> an attempt is made to access a serial port on the second card,
> I get a NULL pointer dereference.
>
>
> This is the relevant output from dmesg:
>
> MOXA Smartio family driver version 1.2
> Tty devices major number = 174, callout devices major number = 175
> Found MOXA C104H/PCI series board(BusNo=0,DevNo=10)
>
>
> The relevant stuff from /proc/pci:
>
> Bus 0, device 10, function 0:
> Serial controller: Moxa Technologies Co Ltd Smartio C104H/PCI (rev 2).
> IRQ 10.
> I/O at 0xa800 [0xa87f].
> I/O at 0xa400 [0xa43f].
> I/O at 0xa000 [0xa00f].
> Bus 0, device 11, function 0:
> Serial controller: Moxa Technologies Co Ltd Smartio C104H/PCI (#2) (rev 2).
> IRQ 11.
> I/O at 0x9800 [0x987f].
> I/O at 0x9400 [0x943f].
> I/O at 0x9000 [0x900f].
Well there you have it: they didn't recognise the second board at all. The dmesg should show it, but does not.
Please try attached patch to mxser.c. I cannot test, I have no two cards (in fact I haven't a single one either ;-). If it works out tell me and send patch to [email protected] with regards from me :-)
Have fun,
Stephan
--- linux/drivers/char/mxser.c-orig Mon Dec 10 19:29:13 2001
+++ linux/drivers/char/mxser.c Mon Dec 10 19:34:36 2001
@@ -614,9 +614,9 @@
n = (sizeof(mxser_pcibrds) / sizeof(mxser_pcibrds[0])) - 1;
index = 0;
for (b = 0; b < n; b++) {
- pdev = pci_find_device(mxser_pcibrds[b].vendor,
- mxser_pcibrds[b].device, pdev);
- if (!pdev || pci_enable_device(pdev))
+ while (pdev = pci_find_device(mxser_pcibrds[b].vendor,
+ mxser_pcibrds[b].device, pdev)) {
+ if (pci_enable_device(pdev))
continue;
hwconf.pdev = pdev;
printk("Found MOXA %s board(BusNo=%d,DevNo=%d)\n",
@@ -646,6 +646,7 @@
}
+ }
}
}
#endif
Stephan von Krawczynski <[email protected]> writes:
> On 10 Dec 2001 18:53:48 +0100
> Christian Laursen <[email protected]> wrote:
>
> > I have a problem when trying to use two of the serial cards known as
> > MOXA C104H/PCI.
> >
> > When only using one, everything works like a charm, but when
> > an attempt is made to access a serial port on the second card,
> > I get a NULL pointer dereference.
> >
> >
> > This is the relevant output from dmesg:
> >
> > MOXA Smartio family driver version 1.2
> > Tty devices major number = 174, callout devices major number = 175
> > Found MOXA C104H/PCI series board(BusNo=0,DevNo=10)
> >
> >
> > The relevant stuff from /proc/pci:
> >
> > Bus 0, device 10, function 0:
> > Serial controller: Moxa Technologies Co Ltd Smartio C104H/PCI (rev 2).
> > IRQ 10.
> > I/O at 0xa800 [0xa87f].
> > I/O at 0xa400 [0xa43f].
> > I/O at 0xa000 [0xa00f].
> > Bus 0, device 11, function 0:
> > Serial controller: Moxa Technologies Co Ltd Smartio C104H/PCI (#2) (rev 2).
> > IRQ 11.
> > I/O at 0x9800 [0x987f].
> > I/O at 0x9400 [0x943f].
> > I/O at 0x9000 [0x900f].
>
> Well there you have it: they didn't recognise the second board at
> all. The dmesg should show it, but does not. Please try attached
> patch to mxser.c. I cannot test, I have no two cards (in fact I
> haven't a single one either ;-). If it works out tell me and send
> patch to [email protected] with regards from me :-)
Well, now it finds both the cards. :)
MOXA Smartio family driver version 1.2
Tty devices major number = 174, callout devices major number = 175
Found MOXA C104H/PCI series board(BusNo=0,DevNo=10)
Found MOXA C104H/PCI series board(BusNo=0,DevNo=11)
However, access to the second one still results in the oops. :-/
--
Best regards
Christian Laursen
> Stephan von Krawczynski <[email protected]> writes:
> Seems I got somewhat closer now.
>
> After reading the documentation again, I realised that I was
accessing
> the wrong device.
>
> I belive I read in another file, that the second board started at
> device 32. However device 8 is the first port on the second board.
>
> And actually that seems to work. (I cant confirm this 100% before
> I get to work tomorrow and actually attach something to the port)
Well, this driver does only support 32 Ports. everyone more crashes
definitely. I haven't seen such a broken source in years. I urge you
to delete the device nodes above 31 to overcome any chance to crash
again.
Most interestingly the moxa-driver is better by far than the mxser. It
seems to me the mxser is _really_ old. If you want to help us all,
please try to contact moxa support and tell them it is high time to
submit a _new_ mxser.c to the kernel tree, because the old (currently
used) one is such a mess. They can do better (proven in moxa.c).
At least a multiboard setup is completely broken. My patch fixes this
but this does not help the main kernel tree.
I cannot submit a patch to marcelo, because I am not the maintainer,
and we all don't want to fork a new mxser-driver apart from the
original.
Oh dear.
Regards,
Stephan
> Most interestingly the moxa-driver is better by far than the mxser. It
> seems to me the mxser is _really_ old. If you want to help us all,
mxser, like the boards the moxa mxser driver supports is very old.
> I cannot submit a patch to marcelo, because I am not the maintainer,
> and we all don't want to fork a new mxser-driver apart from the
> original.
There is no maintainer, and our code base has drifted a fair way from what
moxa originally submitted (being a 2.0 driver with the serial transmit race
bug).
Anyone who wants to beat the mxser driver into shape, go for it.
> There is no maintainer, and our code base has drifted a fair way from what
> moxa originally submitted (being a 2.0 driver with the serial transmit race
> bug).
>
> Anyone who wants to beat the mxser driver into shape, go for it.
I'm using it under 2.4.x, but I missed the rest of this thread - what are
the issues?
Alan Cox <[email protected]> writes:
> > Most interestingly the moxa-driver is better by far than the mxser. It
> > seems to me the mxser is _really_ old. If you want to help us all,
>
> mxser, like the boards the moxa mxser driver supports is very old.
Those boards are still sold though. We bought ours quite recently.
At least they both work now, with Stephan's patch applied.
--
Best regards
Christian Laursen
> > There is no maintainer, and our code base has drifted a fair way
from what
> > moxa originally submitted (being a 2.0 driver with the serial
transmit race
> > bug).
> >
> > Anyone who wants to beat the mxser driver into shape, go for it.
>
> I'm using it under 2.4.x, but I missed the rest of this thread -
what are
> the issues?
Ok. Short summary (on mxser, moxa is different):
- multiple board support is broken
- driver blows up on illegal device minor numbers opened
- no security checks whatsoever on internal array overflows
- Completely broken port-number setup
- No visible NULL-pointer checks regarding dynamic structures
It looks like original taiwanese work: it is usable, but there are so
many dead ends in this code, you won't believe - and I did only look
some few minutes on it.
It desperately needs cleanup.
Listen Tim, if you want to do it, I can help you. But keep in mind, I
have no hardware. So I am probably not the right guy for maintenance.
If you do not feel comfortable, I will try it.
Regards,
Stephan