On Tue, Mar 01, 2016 at 08:10:01AM +0100, Sean Nyekj?r wrote:
> On 2016-02-29 17:48, Greg KH wrote:
> >On Mon, Feb 29, 2016 at 01:47:36PM +0100, Sean Nyekjær wrote:
[..]
> >>Waiting for data to flow and closes og repeates again, most of the time data
> >>is flowing perfectly but sometimes the whole datastream is containing
> >>invalid chars:
> >>
> >>$ cat /dev/ttySC0
> >'cat' is never a good thing to use for serial ports, try using something
> >like minicom or another program that knows it is talking to a serial
> >device.
> >
> >thanks,
> >
> >greg k-h
> >
> Ops
>
> If I open the serialport with minicom it's not pretty :-)
>
> $ minicom -D /dev/ttySC0 -b 115200
> BUG: scheduling while atomic: minicom/287/0x00000002
> 3 locks held by minicom/287:
> #0: (&port->mutex){......}, at: [<80282bf8>] uart_tiocmget+0x20/0x6c
> #1: (&port_lock_key){......}, at: [<80282c10>] uart_tiocmget+0x38/0x6c
> #2: (&map->mutex){......}, at: [<802a759c>] regmap_read+0x30/0x60
> Modules linked in: sc16is7xx regmap_spi usb_f_acm u_serial usb_f_rndis
> g_multi u_ether usb_f_mass_storage libcomposite
> Preemption disabled at:[< (null)>] (null)
>
> CPU: 0 PID: 287 Comm: minicom Not tainted 4.1.15-00136-g27ad049-dirty #7
> Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [<80016850>] (unwind_backtrace) from [<800128a8>] (show_stack+0x10/0x14)
> [<800128a8>] (show_stack) from [<804ab1f4>] (dump_stack+0x80/0xc0)
> [<804ab1f4>] (dump_stack) from [<804a8bec>] (__schedule_bug+0xb0/0xc4)
> [<804a8bec>] (__schedule_bug) from [<804ad1d8>] (__schedule+0x4bc/0x534)
> [<804ad1d8>] (__schedule) from [<804ad290>] (schedule+0x40/0x98)
> [<804ad290>] (schedule) from [<804ad5f0>] (schedule_preempt_disabled+0x14/0x20)
> [<804ad5f0>] (schedule_preempt_disabled) from [<804af30c>] (mutex_lock_nested+0x1b4/0x444)
> [<804af30c>] (mutex_lock_nested) from [<802a759c>] (regmap_read+0x30/0x60)
> [<802a759c>] (regmap_read) from [<7f04a494>] (sc16is7xx_port_read+0x2c/0x38 [sc16is7xx])
> [<7f04a494>] (sc16is7xx_port_read [sc16is7xx]) from [<7f04a4ac>] (sc16is7xx_get_mctrl+0xc/0x4c [sc16is7xx])
> [<7f04a4ac>] (sc16is7xx_get_mctrl [sc16is7xx]) from [<80282c20>] (uart_tiocmget+0x48/0x6c)
> [<80282c20>] (uart_tiocmget) from [<8026ade8>] (tty_ioctl+0x46c/0xc84)
> [<8026ade8>] (tty_ioctl) from [<800f7740>] (do_vfs_ioctl+0x428/0x67c)
> [<800f7740>] (do_vfs_ioctl) from [<800f79c8>] (SyS_ioctl+0x34/0x5c)
> [<800f79c8>] (SyS_ioctl) from [<8000f440>] (ret_fast_syscall+0x0/0x3c)
Ouch. This is caused by "sc16is7xx: implemented get_mctrl";
sc16is7xx_get_mctrl() is invoked under the uart port spinlock; the new
implementation of get_mctrl() tries to read the MSR....but reading
registers over i2c can't be done in atomic context.
I imagine you'll also run into problems with set_mctrl as well.
Josh
Attachment:
signature.asc
Description: PGP signature
