Which tty driver ? serial/msm_serial.c ?
We are using our internal driver, msm_geni_serial.c
Ok no what I need to see is a trace of what each CPU is doing at the
point you detect the problem. That way we can see what the path that
races is.
Below is stack trace running by init in our case on one core
-006|n_tty_open(
| tty = 0xFFFFFFFF477AC880 -> (
| disc_data = 0xFFFFFF80197AD000,
| port = 0xFFFFFFFFEDE40000))
| ldata = 0xFFFFFF80197AD000
| trace_printk_fmt = 0xFFFFFF9F275125F8
-007|tty_ldisc_open.isra.3(
| tty = 0xFFFFFFFF477AC880)
-008|tty_ldisc_setup(
-009|tty_init_dev(
| driver = 0xFFFFFFFFEDE2A480,
| idx = 0)
-010|tty_open_by_driver(inline)
-010|tty_open(
Core 2:
-000|n_tty_receive_buf_common(
| tty = 0xFFFFFFFF477AC880,
| ?)
| ldata_=_0x0
| __func__ = (110, 95, 116, 116, 121, 95, 114, 101, 99, 101, 105,
118, 101, 95, 98, 117, 102, 95, 99, 111, 109, 109, 111, 110, 0)
| __u = (__val = 7079195495121566464, __c = (0))
| c = 127
| ldata = 0xFFFFFFFFF40DF97C
| c = 0
| ldata = 0xFFFFFF9F26F46000
-001|n_tty_receive_buf2(
| tty = 0xFFFFFFFF477AC880,
-002|tty_ldisc_receive_buf(inline)
-002|receive_buf(inline)
-002|flush_to_ldisc(
Please let me know in case some other trace required
We have seen this issue on 4.9 and also one thing i have observed,
before tty is getting reinit in tty_init_dev(),
When yo stop the DMA is it instantaneous or does it cause a final
interrupt after you return from stop_rx ?
To me it still looks like data is being queued after the port is told to
stop but that's not a certainty.
This geni is based on FIFO.
I have also put ftraces and from that we can see open is not able to
finish but there is request of flushing:
kworker/-15514 2.... 35206.979226: workqueue_execute_start:
work struct 0xffffffffede40008: function flush_to_ldisc
kworker/-15514 2.... 35206.979237: bprint:
n_tty_receive_buf_common: <Debug>n_tty_receive_buf_common
tty=0xffffffff477ac880 ldata=(nil)
init-1 4.... 35206.979751:
bprint: n_tty_open: <Debug>n_tty_open
tty=0xffffffff477ac880 ldata=0xffffff80197ad000
there is console service exited before it in all the dumps.
35206.969644: <2> init: Service 'console' (pid 7440) exited with
status 130
35206.969690: <2> init: Sending signal 9 to service 'console' (pid
7440) process group...
35206.970857: <2> init: kill(7440, 9) failed: No such process.
So how can we stop request of receive buff, if we already have tty_port
and tty is getting reinitialized in midway like above
case?
Is the port your console device. If you use a different port as a console
device does the problem go away - that could be a very important detail
as the hangup behaviour for the two is quite different.
Yes , we are using ttymsm0 as console device, this is the only port we
are using.
So it seems here, we are getting flush request when init reinitialize
the tty for same port. Please let me know
if some other debug logs are required.
Regards
Gaurav
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
