i.MX28 AUART driver on 3.14 kernel doesn't work well with hardware flow control

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX28 AUART driver on 3.14 kernel doesn't work well with hardware flow control

1,400 Views
CraigMcQueen
Contributor III

I'm testing a 3.14.17 kernel. I've found that the AUART driver seems to work okay with no flow control, but with hardware flow control turned on, it causes repeated and/or missing characters on RX. E.g. when connected to a modem from picocom:

picocom v1.7

port is        : /dev/ttyAPP0

flowcontrol    : none

baudrate is    : 9600

parity is      : none

databits are   : 8

escape is      : C-a

local echo is  : no

noinit is      : no

noreset is     : no

nolock is      : no

send_cmd is    : sz -vv

receive_cmd is : rz -vv

imap is        :

omap is        :

emap is        : crcrlf,delbs,

Terminal ready

at

OK

at

OK

*** flow: RTS/CTS ***

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

OK

I had pressed Ctrl-A, Ctrl-F in picocom to turn on hardware flow control. Then I typed at[LF] again, and got forever-scrolling OK, with a sample shown above.

Then I tried quitting and restarting picocom, and got a kernel crash:

picocom v1.7

port is        : /dev/ttyAPP0

flowcontrol    : none

baudrate is    : 9600

parity is      : none

databits are   : 8

escape is      : C-a

local echo is  : no

noinit is      : no

[  575.000155] Unable to handle kernel paging request at virtual address c9065e00

[  575.009220] pgd = c6e6c000

[  575.011966] [c9065e00] *pgd=00000000

[  575.015611] Internal error: Oops: 5 [#1] ARM

[  575.019916] Modules linked in: mxs_auart usb_f_rndis u_ether libcomposite configfs

[  575.027667] CPU: 0 PID: 509 Comm: picocom Not tainted 3.14.17-01382-gc14be63-dirty #1

[  575.035539] task: c6ed0000 ti: c78b2000 task.ti: c78b2000

[  575.041001] PC is at kmem_cache_free+0xa0/0x1d4

[  575.045572] LR is at final_putname+0x34/0x50

[  575.049883] pc : [<c00dee04>]    lr : [<c00ef0f0>]    psr: a0000013

[  575.049883] sp : c78b3f10  ip : c78b3f38  fp : c78b3f34

[  575.061397] r10: 00000000  r9 : c6e78c40  r8 : c00ef0f0

[  575.066653] r7 : c6ec8368  r6 : c6d83000  r5 : 4b4f0a0d  r4 : c7801a80

[  575.073210] r3 : c7efc000  r2 : 0008b4f0  r1 : 00000000  r0 : c7801a80

[  575.079770] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user

[  575.086938] Control: 0005317f  Table: 46e6c000  DAC: 00000015

[  575.092713] Process picocom (pid: 509, stack limit = 0xc78b21c0)

[  575.098750] Stack: (0xc78b3f10 to 0xc78b4000)

[  575.103152] 3f00:                                     c06eb43c c6d83000 00000003 c6d83000

[  575.111386] 3f20: c6ec8368 00000020 c78b3f4c c78b3f38 c00ef0f0 c00ded74 c6ee604c c6ec8360

[  575.119616] 3f40: c78b3f94 c78b3f50 c00e42a8 c00ef0cc 00000000 00000000 c78b3f84 00000902

[  575.127843] 3f60: c0040000 00000026 00000100 00000001 00000000 00000000 00008e58 00000005

[  575.136074] 3f80: c0009764 c78b2000 c78b3fa4 c78b3f98 c00e4300 c00e4110 00000000 c78b3fa8

[  575.144301] 3fa0: c0009500 c00e42dc 00000000 00000000 00017240 00000902 00000005 00000000

[  575.152527] 3fc0: 00000000 00000000 00008e58 00000005 00000000 00000000 b6f84fac bea7fd24

[  575.160758] 3fe0: 00000000 bea7fcf4 0000bb60 b6ee45bc 60000010 00017240 280aa820 aaa280aa

[  575.169014] [<c00dee04>] (kmem_cache_free) from [<c00ef0f0>] (final_putname+0x34/0x50)

[  575.176997] [<c00ef0f0>] (final_putname) from [<c00e42a8>] (do_sys_open+0x1a8/0x1cc)

[  575.184798] [<c00e42a8>] (do_sys_open) from [<c00e4300>] (SyS_open+0x34/0x38)

[  575.191995] [<c00e4300>] (SyS_open) from [<c0009500>] (ret_fast_syscall+0x0/0x44)

[  575.199537] Code: e1833a01 e0632622 e59f312c e5933000 (e7931282)

[  575.205686] ---[ end trace f1b66cb68fba87e0 ]---

noreset is     : no

nolock is      : no

send_cmd is    : sz -vv

receive_cmd is : rz -vv

imap is        :

omap is        :

emap is        : crcrlf,delbs,

Segmentation fault

#

# 

I first tried this on our own hardware. I then tried it on the i.MX28 EVK, also running a 3.14.17 kernel and connected to an EVK for the modem, and got the same sort of result.

Can anyone reproduce this behaviour, and recommend a solution?

Labels (1)
Tags (2)
0 Kudos
9 Replies

949 Views
CraigMcQueen
Contributor III

This bug doesn't seem to occur if the serial port is switched to hardware flow control before any bytes are received, and then kept in that mode continuously. That means early in start-up:

stty -F /dev/ttyAPP0 crtscts

Then whenever starting picocom:

picocom -f h /dev/ttyAPP0

When picocom exits, it will restore the previous port state, so it stays in hardware flow control mode. (Similarly for our device, which normally runs a custom serial communications program, which normally configures hardware flow control, and restores the previous port state when it exits.)

In this scenario, the serial port seems to function normally without the bug in received bytes and without any kernel crash.

So I am guessing that the bug occurs when switching the flow control mode from 'none' to 'hardware', or vice-versa, after some bytes have been received, and causes some sort of receive buffer misalignment.

0 Kudos

949 Views
lategoodbye
Senior Contributor I

Hi Craig,

i suggest to reproduce the problem with current stable Kernel 3.17.2 and than post the problem to linux-serial mailing list.

BR Stefan

0 Kudos

949 Views
CraigMcQueen
Contributor III

I've tested it with kernel 3.18-rc4, and the problem is still present. I will post it to the linux-serial mailing list. Edit: posted to linux-serial mailing list.

0 Kudos

949 Views
fabio_estevam
NXP Employee
NXP Employee

Can you check these recent patches from Janusz?

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/drivers/tty/serial/mxs-auart.c?...

It seems he has been working with flow control lately, so you could add him on Cc when reporting the problem on the list.

0 Kudos

949 Views
CraigMcQueen
Contributor III

Funnily enough, I found and used those patches a couple of weeks ago because our project also requires GPIO hardware handshaking lines (I had implemented GPIO hardware handshaking functionality myself for 2.6.35 kernel, but for 3.14 kernel, used Janusz's patches instead).

Those patches don't improve this issue, which applies to the AUART's in-built support of RTS/CTS hardware flow control. (Unless he has modified them lately—I used his patches from his "v4" devicetree mailing list posts from Oct 10 2014.)

0 Kudos

949 Views
fabio_estevam
NXP Employee
NXP Employee

Maybe you could report the issue to linux-serial with Janusz on Cc. I don't have hardware handy to reproduce such behaviour.

0 Kudos

949 Views
CraigMcQueen
Contributor III

I did post to the linux-serial mailing list. Janusz replied to me (off-list) saying maybe it's a missing spinlock, and he hopes to look at it in a week.

0 Kudos

949 Views
lategoodbye
Senior Contributor I

Hi Craig,

this should be the right patch:

http://marc.info/?l=linux-serial&m=141632187904503&q=raw

Currently i don't have the necessary hardware to test it.

Stefan

0 Kudos

949 Views
fabio_estevam
NXP Employee
NXP Employee
0 Kudos