[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RS485 userspace test



I have tested the new serial driver design, in the 2.4.19-pre10 kernel.
I have tested whether I can write to RS485 bus from userspace, with the
RS485 capability on
Basically I enable RS485 in kernel config.
A userspace program open the dev file /dev/ttyS3 then calls the IOCTL to
enable RS485.
I write to the dev file

That runs well if I am the only on the RS485 bus, because if I get an answer
from the device I that also is on the RS485 bus.
Then I get a kernel oops and panic. the answer comes about 10 ms after I
send my message.

I have tested it on kernel 2.4.19-pre8 + new serial patch, and on kernel
2.4.19-pre9 and pre10 without a patch.
Exact same result.


The serial port is set to 9600 parenb (8o1).

By a normal run, (that I can achieve trough a call to the same driver from
another module, and therefore kernelspace).
I get something like the ascii graphic below

data-----|||||||||----|||||||||||-----
rts------___________------------------
         axis send    device answer

But if I do the same thing from userspace, I get this result

data-----|||||||||----|||x|||x|||-----
rts------___________-----_---_--------
         axis send    device answer

As you can see the RTS line makes two short jumps when receiving the answer,
it is probably caused by the kernel going down.

If I turn off my device, so there is no answer. It looks as expected. and no
extra jumps on the RTS line.

data-----|||||||||--------------------
rts------___________------------------
         axis send    device answer

Attached the oops message from the pre8 version (they are similar for all
versions)


BTW: I can _not_ use the method of toggling the RTS directly from userspace,
it is too slow.

-- 
Martin Hansen
Student at SDU Sønderborg. www.sdu.dk
Writing final project at Danfoss drives A/S. http://drives.danfoss.com

Tlf: 74 88 54 62

Sniffing /dev/ttyS0 at 115200 Baud
Scheduling in interrupt
kernel BUG at sched.c:566!
Scheduling in interrupt
kernel BUG at sched.c:566!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
Oops: 0002
IRP: c0005ccc SRP: c0005c38 DCCR: 00000484 USP: 9ffffe54 MOF: 00000000
 r0: c0008374  r1: c00cc000   r2: c00caec0  r3: c00c66a6
 r4: c00cc028  r5: 00000000   r6: c00c675e  r7: c00c6762
 r8: c00cdd74  r9: 00000000  r10: 0000001b r11: 00000001
r12: c00cc03c r13: c00cc03c oR10: 0000001b
R_MMU_CAUSE: 00001111
Process swapper (pid: 0, stackpage=c00cc000)

Stack from 9ffffe54:
       00000000 000806e4 35640abc 355973e8 9ffffea4 000827b4 00080346 35640abc
       355887be 00000000 00000000 00000000 00000000 00000000 00080400 35568ce4
       0008042c 000806e4 3556064c 9ffffea0 9fffff5d 00000000 9fffff64 9fffff7e
Call Trace:
Stack from c00cdc0c:
       c0008374 c00cdd44 c0044082 c00441e6 00000001 00000000 00000000 c00c66a6
       c00cdd00 c05a2000 c00cdd00 c0044290 c0008374 c0046578 c00cdd74 c00c6762
       c00c675e 00000000 c00cc028 c00c66a6 c00cdd00 c05a2000 00000000 00000002
Call Trace: [<c0008374>] [<c0044082>] [<c00441e6>] [<c0044290>] [<c0008374>] [<c0046578>] [<c0044d10>]
       [<c0044382>] [<c0008184>] [<c0046374>] [<c0008374>] [<c0043e9a>] [<c0008374>] [<c0005c38>] [<c0005ccc>]
       [<dbed0012>] [<c0005b94>] [<c0005ab6>] [<c0060c8e>] [<c004b7a8>] [<c005ff02>] [<c0049512>] [<c0049b64>]
       [<c004a0ca>] [<c0044ce2>] [<c0044382>] [<c0049312>] [<c000bddc>] [<c000e320>] [<c000bd28>] [<c000bc4e>]
       [<c000ba04>] [<c0044d10>] [<c004432c>] [<c00431c8>] [<c0005c0c>] [<c00431c8>] [<c000407a>]
Code: 40 11 6d da 3c 11 6c 9e 04 91 ed db (ed) 9b 7c 8a 14 12 71 8a 94 12 6f 3e
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing