> > 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
It seems I made a mistake in that patch then. Do you really think
set_mctrl() will give problems as well? I'm asking because set_mctrl()
uses the queue_kthread_work() function to get things done.
I'll investigate how to solve this.
Is there a way to release the spinlock? And should I?
I could use queue_kthread_work() to do the reading, but how to get the
result to return from get_mctrl() then?
Maarten
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
