On 04/18/2016 07:18 AM, Matwey V. Kornilov wrote: > 2016-04-18 9:55 GMT+03:00 Jiri Slaby <jslaby@xxxxxxx>: >> On 04/17/2016, 02:33 PM, Matwey V. Kornilov wrote: >>> Hello, >>> >>> When running 4.6-rc3 (please find used config attached) on BeagleBone Black with 8250_omap serial driver I see the following hung. What uart # (0-5) are you using? Are you using not-yet-mainline patches to 8250 driver (like for gpio modem control)? >>> When test application a.out run twice (test.c source code attached here) the following happens: >>> >>> # ./a.out # ./a.out >>> (hung here, may be interrupted with Ctrl-C) >>> >>> Trace from echo t > /proc/sysrq-trigger is the following: >>> >>> апр 17 12:29:23 nohostname kernel: a.out S c0c3544c 0 922 882 0x00000000 >>> апр 17 12:29:23 nohostname kernel: [<c0c3544c>] (__schedule) from [<c0c3597c>] (schedule+0x5c/0xd0) >>> апр 17 12:29:23 nohostname kernel: [<c0c3597c>] (schedule) from [<c0794820>] (tty_port_block_til_ready+0x11c/0x2a0) >>> апр 17 12:29:23 nohostname kernel: [<c0794820>] (tty_port_block_til_ready) from [<c07abfb0>] (uart_open+0x11c/0x158) >> ... >>> >>> I don't think that open() user-space call should be blocked under such circumstances, so I think that this is rather an issue within the kernel. >>> I've found that the effect dissapears when termios calls are dropped from test.c Assuming you are _not_ using gpio modem control, this shouldn't happen because the driver should report TIOCM_CAR always on if DCD is not pinned out for exactly this reason. IOW, could be driver bug. Regards, Peter Hurley >> I suppose the memset in the program cleared CLOCAL and the subsequent >> open waits for carrier... >> > > The same program doesn't hang when fdti_sio based /dev/ttyUSB is being used. > >> thanks, >> -- >> js >> suse labs >> > > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
