[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

         axis send    device answer

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

         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.

         axis send    device answer

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

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