Fixed
Created: Mar 28, 2016
Updated: Sep 8, 2018
Resolved Date: May 5, 2016
Found In Version: 7.0.0.11
Fix Version: 7.0.0.16
Severity: Standard
Applicable for: Wind River Linux 7
Component/s: BSP, Kernel
* Root Cause Analysis by customer:
After a lot of debugging it was finally determined that the kernel exception was occurring during a serial IRQ in the line discipline driver.
It was discovered that the Ti-WiLink UART interface to the Baytrail does not
utilize the standard Bluetooth (HCI) Line Discipline driver (drivers/Bluetooth/hci_ldisc.c). Instead there is a custom TI specific line discipline driver that handles a TI proprietary HCI_LL protocol (for Bluetooth), and also handles firmware update processing (see: drivers/misc/ti-st/st_core.c).
The cause of the crash was a nasty deadlock bug during a TX wakeup event. The tty layer of the kernel would attempt to wakeup the line discipline driver during a tx completion (i.e. sending of data to the Bluetooth chip). The tty driver makes this wakeup call with IRQs disabled and a lock taken (since it is within the context of an IRQ). The TI line discipline driver was then attempting to call back into the tty driver to process another write, but because the port lock had not been released yet a deadlock would occur.
The correct behavior is that during a wakeup call the TI line discipline driver should schedule the work on a kernel workqueue. This will ensure that when the workqueue is processed the tty driver will not deadlock attempting to obtain a lock on the port.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/misc/ti-st/st_core.c?id=b05b7c7cc0324524dcda7fa7c2be1255290ee416
Prior to patch the bug can be readily produced by streaming BLE data. It has been ensured that the bug existed in customer's production tree prior to bringing in the v3.15 HCI driver for LE Privacy Support. The bug is unrelated to this driver (see the RCA).
