* [BUG] atmel: spi: scheduling while atomic
@ 2014-03-04 14:29 Jiří Prchal
2014-03-04 21:40 ` Alexandre Belloni
0 siblings, 1 reply; 11+ messages in thread
From: Jiří Prchal @ 2014-03-04 14:29 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I discovered some problem when I access anything on SPI. But it seems to work correctly, only log is full of this
messages. I've tried kernels 3.13.0 and 3.14.0, both are the same.
[ 0.875000] atmel_spi f0000000.spi: version: 0x212
[ 0.878906] atmel_spi f0000000.spi: Using dma0chan0 (tx) and dma0chan1 (rx) for DMA transfers
[ 0.882812] atmel_spi f0000000.spi: Atmel SPI Controller at 0xf0000000 (irq 28)
...
[ 0.890625] BUG: scheduling while atomic: spi0/383/0x00000002
[ 0.894531] Modules linked in:
[ 0.894531] CPU: 0 PID: 383 Comm: spi0 Not tainted 3.14.0-rc4_cpm9g25+ #1
[ 0.894531] [<c000d9f4>] (unwind_backtrace) from [<c000bdc0>] (show_stack+0x10/0x14)
[ 0.894531] [<c000bdc0>] (show_stack) from [<c003a224>] (__schedule_bug+0x48/0x60)
[ 0.894531] [<c003a224>] (__schedule_bug) from [<c0390294>] (__schedule+0x60/0x484)
[ 0.894531] [<c0390294>] (__schedule) from [<c038feac>] (schedule_timeout+0x17c/0x1ac)
[ 0.894531] [<c038feac>] (schedule_timeout) from [<c039111c>] (wait_for_common+0x10c/0x1f0)
[ 0.894531] [<c039111c>] (wait_for_common) from [<c0249228>] (atmel_spi_transfer_one_message+0x71c/0xa48)
[ 0.894531] [<c0249228>] (atmel_spi_transfer_one_message) from [<c0246624>] (spi_pump_messages+0x210/0x238)
[ 0.894531] [<c0246624>] (spi_pump_messages) from [<c00343d0>] (kthread_worker_fn+0x15c/0x1b4)
[ 0.894531] [<c00343d0>] (kthread_worker_fn) from [<c0034534>] (kthread+0xb8/0xcc)
[ 0.894531] [<c0034534>] (kthread) from [<c0009510>] (ret_from_fork+0x14/0x24)
[ 0.898437] at25 spi0.0: 128 KByte at25 eeprom, pagesize 512
...
[ 3204.558593] BUG: scheduling while atomic: spi0/383/0x00000002
[ 3204.562500] Modules linked in:
[ 3204.562500] CPU: 0 PID: 383 Comm: spi0 Tainted: G W 3.14.0-rc4_cpm9g25+ #1
[ 3204.562500] [<c000d9f4>] (unwind_backtrace) from [<c000bdc0>] (show_stack+0x10/0x14)
[ 3204.566406] [<c000bdc0>] (show_stack) from [<c003a224>] (__schedule_bug+0x48/0x60)
[ 3204.566406] [<c003a224>] (__schedule_bug) from [<c0390294>] (__schedule+0x60/0x484)
[ 3204.566406] [<c0390294>] (__schedule) from [<c038feac>] (schedule_timeout+0x17c/0x1ac)
[ 3204.566406] [<c038feac>] (schedule_timeout) from [<c039111c>] (wait_for_common+0x10c/0x1f0)
[ 3204.566406] [<c039111c>] (wait_for_common) from [<c0249228>] (atmel_spi_transfer_one_message+0x71c/0xa48)
[ 3204.566406] [<c0249228>] (atmel_spi_transfer_one_message) from [<c0246624>] (spi_pump_messages+0x210/0x238)
[ 3204.566406] [<c0246624>] (spi_pump_messages) from [<c00343d0>] (kthread_worker_fn+0x15c/0x1b4)
[ 3204.566406] [<c00343d0>] (kthread_worker_fn) from [<c0034534>] (kthread+0xb8/0xcc)
[ 3204.566406] [<c0034534>] (kthread) from [<c0009510>] (ret_from_fork+0x14/0x24)
[ 3204.570312] BUG: scheduling while atomic: spi0/383/0x00000002
[ 3204.574218] Modules linked in:
[ 3204.574218] CPU: 0 PID: 383 Comm: spi0 Tainted: G W 3.14.0-rc4_cpm9g25+ #1
[ 3204.574218] [<c000d9f4>] (unwind_backtrace) from [<c000bdc0>] (show_stack+0x10/0x14)
[ 3204.574218] [<c000bdc0>] (show_stack) from [<c003a224>] (__schedule_bug+0x48/0x60)
[ 3204.574218] [<c003a224>] (__schedule_bug) from [<c0390294>] (__schedule+0x60/0x484)
[ 3204.574218] [<c0390294>] (__schedule) from [<c038feac>] (schedule_timeout+0x17c/0x1ac)
[ 3204.574218] [<c038feac>] (schedule_timeout) from [<c039111c>] (wait_for_common+0x10c/0x1f0)
[ 3204.574218] [<c039111c>] (wait_for_common) from [<c0249228>] (atmel_spi_transfer_one_message+0x71c/0xa48)
[ 3204.574218] [<c0249228>] (atmel_spi_transfer_one_message) from [<c0246624>] (spi_pump_messages+0x210/0x238)
[ 3204.574218] [<c0246624>] (spi_pump_messages) from [<c00343d0>] (kthread_worker_fn+0x15c/0x1b4)
[ 3204.574218] [<c00343d0>] (kthread_worker_fn) from [<c0034534>] (kthread+0xb8/0xcc)
[ 3204.574218] [<c0034534>] (kthread) from [<c0009510>] (ret_from_fork+0x14/0x24)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [BUG] atmel: spi: scheduling while atomic
2014-03-04 14:29 [BUG] atmel: spi: scheduling while atomic Jiří Prchal
@ 2014-03-04 21:40 ` Alexandre Belloni
2014-03-05 6:56 ` Jiří Prchal
0 siblings, 1 reply; 11+ messages in thread
From: Alexandre Belloni @ 2014-03-04 21:40 UTC (permalink / raw)
To: linux-arm-kernel
Hi Ji??,
Thank you for that report.
On 04/03/2014 at 15:29:16 +0100, Ji?? Prchal wrote :
> Hi,
> I discovered some problem when I access anything on SPI. But it
> seems to work correctly, only log is full of this messages. I've
> tried kernels 3.13.0 and 3.14.0, both are the same.
>
> [ 0.875000] atmel_spi f0000000.spi: version: 0x212
> [ 0.878906] atmel_spi f0000000.spi: Using dma0chan0 (tx) and dma0chan1 (rx) for DMA transfers
> [ 0.882812] atmel_spi f0000000.spi: Atmel SPI Controller at 0xf0000000 (irq 28)
> ...
For now, as a work around, I would suggest disabling dma. I believe it
will solve that particular issue but I didn't try. I would be grateful
if you could post the result.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* [BUG] atmel: spi: scheduling while atomic
2014-03-04 21:40 ` Alexandre Belloni
@ 2014-03-05 6:56 ` Jiří Prchal
2014-03-07 22:58 ` Alexandre Belloni
0 siblings, 1 reply; 11+ messages in thread
From: Jiří Prchal @ 2014-03-05 6:56 UTC (permalink / raw)
To: linux-arm-kernel
Hi Alex,
I have a bad news, disabling dma does not help.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 3.14.0-rc4_cpm9g25+ (prchal at prchal) (gcc version 4.5.2 (GCC) ) #1 PREEMPT Tue Mar 4
14:28:23 CET 2014
[ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
...
[ 0.878906] atmel_spi f0000000.spi: version: 0x212
[ 0.882812] of_dma_request_slave_channel: dma-names property of node '/ahb/apb/spi at f0000000' missing or empty
[ 0.886718] atmel_spi f0000000.spi: DMA TX channel not available, SPI unable to use DMA
[ 0.890625] atmel_spi f0000000.spi: Atmel SPI Controller using PIO only
[ 0.894531] atmel_spi f0000000.spi: Atmel SPI Controller at 0xf0000000 (irq 28)
...
[ 0.902343] BUG: scheduling while atomic: spi0/383/0x00000002
[ 0.906250] Modules linked in:
[ 0.906250] CPU: 0 PID: 383 Comm: spi0 Not tainted 3.14.0-rc4_cpm9g25+ #1
[ 0.906250] [<c000d9f4>] (unwind_backtrace) from [<c000bdc0>] (show_stack+0x10/0x14)
[ 0.906250] [<c000bdc0>] (show_stack) from [<c003a224>] (__schedule_bug+0x48/0x60)
[ 0.906250] [<c003a224>] (__schedule_bug) from [<c0390294>] (__schedule+0x60/0x484)
[ 0.906250] [<c0390294>] (__schedule) from [<c038feac>] (schedule_timeout+0x17c/0x1ac)
[ 0.906250] [<c038feac>] (schedule_timeout) from [<c039111c>] (wait_for_common+0x10c/0x1f0)
[ 0.906250] [<c039111c>] (wait_for_common) from [<c0249228>] (atmel_spi_transfer_one_message+0x71c/0xa48)
[ 0.906250] [<c0249228>] (atmel_spi_transfer_one_message) from [<c0246624>] (spi_pump_messages+0x210/0x238)
[ 0.906250] [<c0246624>] (spi_pump_messages) from [<c00343d0>] (kthread_worker_fn+0x15c/0x1b4)
[ 0.906250] [<c00343d0>] (kthread_worker_fn) from [<c0034534>] (kthread+0xb8/0xcc)
[ 0.906250] [<c0034534>] (kthread) from [<c0009510>] (ret_from_fork+0x14/0x24)
[ 0.906250] at25 spi0.0: 128 KByte at25 eeprom, pagesize 512
...
[ 62.527343] BUG: scheduling while atomic: spi0/383/0x00000002
[ 62.531250] Modules linked in:
[ 62.531250] CPU: 0 PID: 383 Comm: spi0 Tainted: G W 3.14.0-rc4_cpm9g25+ #1
[ 62.531250] [<c000d9f4>] (unwind_backtrace) from [<c000bdc0>] (show_stack+0x10/0x14)
[ 62.531250] [<c000bdc0>] (show_stack) from [<c003a224>] (__schedule_bug+0x48/0x60)
[ 62.531250] [<c003a224>] (__schedule_bug) from [<c0390294>] (__schedule+0x60/0x484)
[ 62.531250] [<c0390294>] (__schedule) from [<c038feac>] (schedule_timeout+0x17c/0x1ac)
[ 62.531250] [<c038feac>] (schedule_timeout) from [<c039111c>] (wait_for_common+0x10c/0x1f0)
[ 62.531250] [<c039111c>] (wait_for_common) from [<c0249228>] (atmel_spi_transfer_one_message+0x71c/0xa48)
[ 62.531250] [<c0249228>] (atmel_spi_transfer_one_message) from [<c0246624>] (spi_pump_messages+0x210/0x238)
[ 62.531250] [<c0246624>] (spi_pump_messages) from [<c00343d0>] (kthread_worker_fn+0x15c/0x1b4)
[ 62.531250] [<c00343d0>] (kthread_worker_fn) from [<c0034534>] (kthread+0xb8/0xcc)
[ 62.531250] [<c0034534>] (kthread) from [<c0009510>] (ret_from_fork+0x14/0x24)
Dne 4.3.2014 22:40, Alexandre Belloni napsal(a):
> Hi Ji??,
>
> Thank you for that report.
>
> On 04/03/2014 at 15:29:16 +0100, Ji?? Prchal wrote :
>> Hi,
>> I discovered some problem when I access anything on SPI. But it
>> seems to work correctly, only log is full of this messages. I've
>> tried kernels 3.13.0 and 3.14.0, both are the same.
>>
>> [ 0.875000] atmel_spi f0000000.spi: version: 0x212
>> [ 0.878906] atmel_spi f0000000.spi: Using dma0chan0 (tx) and dma0chan1 (rx) for DMA transfers
>> [ 0.882812] atmel_spi f0000000.spi: Atmel SPI Controller at 0xf0000000 (irq 28)
>> ...
>
> For now, as a work around, I would suggest disabling dma. I believe it
> will solve that particular issue but I didn't try. I would be grateful
> if you could post the result.
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [BUG] atmel: spi: scheduling while atomic
2014-03-05 6:56 ` Jiří Prchal
@ 2014-03-07 22:58 ` Alexandre Belloni
2014-03-08 0:41 ` Rabin Vincent
2014-03-08 0:46 ` Stephen Boyd
0 siblings, 2 replies; 11+ messages in thread
From: Alexandre Belloni @ 2014-03-07 22:58 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On 05/03/2014 at 07:56:04 +0100, Ji?? Prchal wrote :
> Hi Alex,
> I have a bad news, disabling dma does not help.
>
> [ 0.000000] Booting Linux on physical CPU 0x0
> [ 0.000000] Linux version 3.14.0-rc4_cpm9g25+ (prchal at prchal)
> (gcc version 4.5.2 (GCC) ) #1 PREEMPT Tue Mar 4 14:28:23 CET 2014
> [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
> ...
> [ 0.878906] atmel_spi f0000000.spi: version: 0x212
> [ 0.882812] of_dma_request_slave_channel: dma-names property of node '/ahb/apb/spi at f0000000' missing or empty
> [ 0.886718] atmel_spi f0000000.spi: DMA TX channel not available, SPI unable to use DMA
> [ 0.890625] atmel_spi f0000000.spi: Atmel SPI Controller using PIO only
> [ 0.894531] atmel_spi f0000000.spi: Atmel SPI Controller at 0xf0000000 (irq 28)
> ...
> [ 0.902343] BUG: scheduling while atomic: spi0/383/0x00000002
> [ 0.906250] Modules linked in:
> [ 0.906250] CPU: 0 PID: 383 Comm: spi0 Not tainted 3.14.0-rc4_cpm9g25+ #1
> [ 0.906250] [<c000d9f4>] (unwind_backtrace) from [<c000bdc0>] (show_stack+0x10/0x14)
> [ 0.906250] [<c000bdc0>] (show_stack) from [<c003a224>] (__schedule_bug+0x48/0x60)
> [ 0.906250] [<c003a224>] (__schedule_bug) from [<c0390294>] (__schedule+0x60/0x484)
> [ 0.906250] [<c0390294>] (__schedule) from [<c038feac>] (schedule_timeout+0x17c/0x1ac)
> [ 0.906250] [<c038feac>] (schedule_timeout) from [<c039111c>] (wait_for_common+0x10c/0x1f0)
> [ 0.906250] [<c039111c>] (wait_for_common) from [<c0249228>] (atmel_spi_transfer_one_message+0x71c/0xa48)
> [ 0.906250] [<c0249228>] (atmel_spi_transfer_one_message) from [<c0246624>] (spi_pump_messages+0x210/0x238)
> [ 0.906250] [<c0246624>] (spi_pump_messages) from [<c00343d0>] (kthread_worker_fn+0x15c/0x1b4)
> [ 0.906250] [<c00343d0>] (kthread_worker_fn) from [<c0034534>] (kthread+0xb8/0xcc)
> [ 0.906250] [<c0034534>] (kthread) from [<c0009510>] (ret_from_fork+0x14/0x24)
> [ 0.906250] at25 spi0.0: 128 KByte at25 eeprom, pagesize 512
> ...
> [ 62.527343] BUG: scheduling while atomic: spi0/383/0x00000002
> [ 62.531250] Modules linked in:
> [ 62.531250] CPU: 0 PID: 383 Comm: spi0 Tainted: G W 3.14.0-rc4_cpm9g25+ #1
> [ 62.531250] [<c000d9f4>] (unwind_backtrace) from [<c000bdc0>] (show_stack+0x10/0x14)
> [ 62.531250] [<c000bdc0>] (show_stack) from [<c003a224>] (__schedule_bug+0x48/0x60)
> [ 62.531250] [<c003a224>] (__schedule_bug) from [<c0390294>] (__schedule+0x60/0x484)
> [ 62.531250] [<c0390294>] (__schedule) from [<c038feac>] (schedule_timeout+0x17c/0x1ac)
> [ 62.531250] [<c038feac>] (schedule_timeout) from [<c039111c>] (wait_for_common+0x10c/0x1f0)
> [ 62.531250] [<c039111c>] (wait_for_common) from [<c0249228>] (atmel_spi_transfer_one_message+0x71c/0xa48)
> [ 62.531250] [<c0249228>] (atmel_spi_transfer_one_message) from [<c0246624>] (spi_pump_messages+0x210/0x238)
> [ 62.531250] [<c0246624>] (spi_pump_messages) from [<c00343d0>] (kthread_worker_fn+0x15c/0x1b4)
> [ 62.531250] [<c00343d0>] (kthread_worker_fn) from [<c0034534>] (kthread+0xb8/0xcc)
> [ 62.531250] [<c0034534>] (kthread) from [<c0009510>] (ret_from_fork+0x14/0x24)
>
>
So I tried, both with an at91sam9rl-ek and an at91sam9m10-g45-ek and I
don't observe that warning. Those boards have an AT45 dataflash do you
see that with other spi devices if you have any ?
Actually, I'm not quite sure how spi_pump_messages can be called from an
atomic context.
Could you share your .config (maybe on pastebin) ?
> Dne 4.3.2014 22:40, Alexandre Belloni napsal(a):
> >Hi Ji??,
> >
> >Thank you for that report.
> >
> >On 04/03/2014 at 15:29:16 +0100, Ji?? Prchal wrote :
> >>Hi,
> >>I discovered some problem when I access anything on SPI. But it
> >>seems to work correctly, only log is full of this messages. I've
> >>tried kernels 3.13.0 and 3.14.0, both are the same.
> >>
> >>[ 0.875000] atmel_spi f0000000.spi: version: 0x212
> >>[ 0.878906] atmel_spi f0000000.spi: Using dma0chan0 (tx) and dma0chan1 (rx) for DMA transfers
> >>[ 0.882812] atmel_spi f0000000.spi: Atmel SPI Controller at 0xf0000000 (irq 28)
> >>...
> >
> >For now, as a work around, I would suggest disabling dma. I believe it
> >will solve that particular issue but I didn't try. I would be grateful
> >if you could post the result.
> >
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* [BUG] atmel: spi: scheduling while atomic
2014-03-07 22:58 ` Alexandre Belloni
@ 2014-03-08 0:41 ` Rabin Vincent
2014-03-10 8:11 ` Jiří Prchal
2014-03-08 0:46 ` Stephen Boyd
1 sibling, 1 reply; 11+ messages in thread
From: Rabin Vincent @ 2014-03-08 0:41 UTC (permalink / raw)
To: linux-arm-kernel
2014-03-07 23:58 GMT+01:00 Alexandre Belloni
<alexandre.belloni@free-electrons.com>:
> On 05/03/2014 at 07:56:04 +0100, Ji?? Prchal wrote :
>> [ 0.902343] BUG: scheduling while atomic: spi0/383/0x00000002
>> [ 0.906250] Modules linked in:
>> [ 0.906250] CPU: 0 PID: 383 Comm: spi0 Not tainted 3.14.0-rc4_cpm9g25+ #1
>> [ 0.906250] [<c000d9f4>] (unwind_backtrace) from [<c000bdc0>] (show_stack+0x10/0x14)
>> [ 0.906250] [<c000bdc0>] (show_stack) from [<c003a224>] (__schedule_bug+0x48/0x60)
>> [ 0.906250] [<c003a224>] (__schedule_bug) from [<c0390294>] (__schedule+0x60/0x484)
>> [ 0.906250] [<c0390294>] (__schedule) from [<c038feac>] (schedule_timeout+0x17c/0x1ac)
>> [ 0.906250] [<c038feac>] (schedule_timeout) from [<c039111c>] (wait_for_common+0x10c/0x1f0)
>> [ 0.906250] [<c039111c>] (wait_for_common) from [<c0249228>] (atmel_spi_transfer_one_message+0x71c/0xa48)
>> [ 0.906250] [<c0249228>] (atmel_spi_transfer_one_message) from [<c0246624>] (spi_pump_messages+0x210/0x238)
>> [ 0.906250] [<c0246624>] (spi_pump_messages) from [<c00343d0>] (kthread_worker_fn+0x15c/0x1b4)
>> [ 0.906250] [<c00343d0>] (kthread_worker_fn) from [<c0034534>] (kthread+0xb8/0xcc)
>> [ 0.906250] [<c0034534>] (kthread) from [<c0009510>] (ret_from_fork+0x14/0x24)
>> [ 0.906250] at25 spi0.0: 128 KByte at25 eeprom, pagesize 512
>
> Actually, I'm not quite sure how spi_pump_messages can be called from an
> atomic context.
spi_pump_messages() is not called from atomic context. Rather,
atmel_spi_transfer_one_message() does a spin_lock_irqsave() (via
atmel_spi_lock()) and then calls atmel_spi_one_transfer(), which calls
wait_for_completion_timeout(). That's why schedule is being called
from atomic context. This was introduced by 8090d6d1a4 ("spi: atmel:
Refactor spi-atmel to use SPI framework queue"). I think you should
see the warning with CONFIG_PREEMPT=y.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [BUG] atmel: spi: scheduling while atomic
2014-03-07 22:58 ` Alexandre Belloni
2014-03-08 0:41 ` Rabin Vincent
@ 2014-03-08 0:46 ` Stephen Boyd
1 sibling, 0 replies; 11+ messages in thread
From: Stephen Boyd @ 2014-03-08 0:46 UTC (permalink / raw)
To: linux-arm-kernel
On 03/07/14 14:58, Alexandre Belloni wrote:
> Hi,
>
> On 05/03/2014 at 07:56:04 +0100, Ji?? Prchal wrote :
>> Hi Alex,
>> I have a bad news, disabling dma does not help.
>>
>> [ 0.000000] Booting Linux on physical CPU 0x0
>> [ 0.000000] Linux version 3.14.0-rc4_cpm9g25+ (prchal at prchal)
>> (gcc version 4.5.2 (GCC) ) #1 PREEMPT Tue Mar 4 14:28:23 CET 2014
>> [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
>> ...
>> [ 0.878906] atmel_spi f0000000.spi: version: 0x212
>> [ 0.882812] of_dma_request_slave_channel: dma-names property of node '/ahb/apb/spi at f0000000' missing or empty
>> [ 0.886718] atmel_spi f0000000.spi: DMA TX channel not available, SPI unable to use DMA
>> [ 0.890625] atmel_spi f0000000.spi: Atmel SPI Controller using PIO only
>> [ 0.894531] atmel_spi f0000000.spi: Atmel SPI Controller at 0xf0000000 (irq 28)
>> ...
>> [ 0.902343] BUG: scheduling while atomic: spi0/383/0x00000002
>> [ 0.906250] Modules linked in:
>> [ 0.906250] CPU: 0 PID: 383 Comm: spi0 Not tainted 3.14.0-rc4_cpm9g25+ #1
>> [ 0.906250] [<c000d9f4>] (unwind_backtrace) from [<c000bdc0>] (show_stack+0x10/0x14)
>> [ 0.906250] [<c000bdc0>] (show_stack) from [<c003a224>] (__schedule_bug+0x48/0x60)
>> [ 0.906250] [<c003a224>] (__schedule_bug) from [<c0390294>] (__schedule+0x60/0x484)
>> [ 0.906250] [<c0390294>] (__schedule) from [<c038feac>] (schedule_timeout+0x17c/0x1ac)
>> [ 0.906250] [<c038feac>] (schedule_timeout) from [<c039111c>] (wait_for_common+0x10c/0x1f0)
>> [ 0.906250] [<c039111c>] (wait_for_common) from [<c0249228>] (atmel_spi_transfer_one_message+0x71c/0xa48)
>> [ 0.906250] [<c0249228>] (atmel_spi_transfer_one_message) from [<c0246624>] (spi_pump_messages+0x210/0x238)
>> [ 0.906250] [<c0246624>] (spi_pump_messages) from [<c00343d0>] (kthread_worker_fn+0x15c/0x1b4)
>> [ 0.906250] [<c00343d0>] (kthread_worker_fn) from [<c0034534>] (kthread+0xb8/0xcc)
>> [ 0.906250] [<c0034534>] (kthread) from [<c0009510>] (ret_from_fork+0x14/0x24)
>> [ 0.906250] at25 spi0.0: 128 KByte at25 eeprom, pagesize 512
>> ...
>> [ 62.527343] BUG: scheduling while atomic: spi0/383/0x00000002
>> [ 62.531250] Modules linked in:
>> [ 62.531250] CPU: 0 PID: 383 Comm: spi0 Tainted: G W 3.14.0-rc4_cpm9g25+ #1
>> [ 62.531250] [<c000d9f4>] (unwind_backtrace) from [<c000bdc0>] (show_stack+0x10/0x14)
>> [ 62.531250] [<c000bdc0>] (show_stack) from [<c003a224>] (__schedule_bug+0x48/0x60)
>> [ 62.531250] [<c003a224>] (__schedule_bug) from [<c0390294>] (__schedule+0x60/0x484)
>> [ 62.531250] [<c0390294>] (__schedule) from [<c038feac>] (schedule_timeout+0x17c/0x1ac)
>> [ 62.531250] [<c038feac>] (schedule_timeout) from [<c039111c>] (wait_for_common+0x10c/0x1f0)
>> [ 62.531250] [<c039111c>] (wait_for_common) from [<c0249228>] (atmel_spi_transfer_one_message+0x71c/0xa48)
>> [ 62.531250] [<c0249228>] (atmel_spi_transfer_one_message) from [<c0246624>] (spi_pump_messages+0x210/0x238)
>> [ 62.531250] [<c0246624>] (spi_pump_messages) from [<c00343d0>] (kthread_worker_fn+0x15c/0x1b4)
>> [ 62.531250] [<c00343d0>] (kthread_worker_fn) from [<c0034534>] (kthread+0xb8/0xcc)
>> [ 62.531250] [<c0034534>] (kthread) from [<c0009510>] (ret_from_fork+0x14/0x24)
>>
>>
> So I tried, both with an at91sam9rl-ek and an at91sam9m10-g45-ek and I
> don't observe that warning. Those boards have an AT45 dataflash do you
> see that with other spi devices if you have any ?
>
> Actually, I'm not quite sure how spi_pump_messages can be called from an
> atomic context.
It isn't. It looks like atmel_spi_transfer_one_message() calls
atmel_spi_lock() which is a thing wrapper around spinlock_irqsave() and
then atmel_spi_one_transfer() is called which eventually calls
wait_for_completion_timeout().
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 11+ messages in thread
* [BUG] atmel: spi: scheduling while atomic
2014-03-08 0:41 ` Rabin Vincent
@ 2014-03-10 8:11 ` Jiří Prchal
2014-03-10 9:08 ` Yang, Wenyou
0 siblings, 1 reply; 11+ messages in thread
From: Jiří Prchal @ 2014-03-10 8:11 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
at first: warning is on all spi devices.
at second: its with CONFIG_PREEMPT=y, without (# CONFIG_PREEMPT_RCU is not set) is OK, but I wonder if this config will
be fast enough for our usage (nearly RT)?
Dne 8.3.2014 01:41, Rabin Vincent napsal(a):
> 2014-03-07 23:58 GMT+01:00 Alexandre Belloni
> <alexandre.belloni@free-electrons.com>:
>> On 05/03/2014 at 07:56:04 +0100, Ji?? Prchal wrote :
>>> [ 0.902343] BUG: scheduling while atomic: spi0/383/0x00000002
>>> [ 0.906250] Modules linked in:
>>> [ 0.906250] CPU: 0 PID: 383 Comm: spi0 Not tainted 3.14.0-rc4_cpm9g25+ #1
>>> [ 0.906250] [<c000d9f4>] (unwind_backtrace) from [<c000bdc0>] (show_stack+0x10/0x14)
>>> [ 0.906250] [<c000bdc0>] (show_stack) from [<c003a224>] (__schedule_bug+0x48/0x60)
>>> [ 0.906250] [<c003a224>] (__schedule_bug) from [<c0390294>] (__schedule+0x60/0x484)
>>> [ 0.906250] [<c0390294>] (__schedule) from [<c038feac>] (schedule_timeout+0x17c/0x1ac)
>>> [ 0.906250] [<c038feac>] (schedule_timeout) from [<c039111c>] (wait_for_common+0x10c/0x1f0)
>>> [ 0.906250] [<c039111c>] (wait_for_common) from [<c0249228>] (atmel_spi_transfer_one_message+0x71c/0xa48)
>>> [ 0.906250] [<c0249228>] (atmel_spi_transfer_one_message) from [<c0246624>] (spi_pump_messages+0x210/0x238)
>>> [ 0.906250] [<c0246624>] (spi_pump_messages) from [<c00343d0>] (kthread_worker_fn+0x15c/0x1b4)
>>> [ 0.906250] [<c00343d0>] (kthread_worker_fn) from [<c0034534>] (kthread+0xb8/0xcc)
>>> [ 0.906250] [<c0034534>] (kthread) from [<c0009510>] (ret_from_fork+0x14/0x24)
>>> [ 0.906250] at25 spi0.0: 128 KByte at25 eeprom, pagesize 512
>>
>> Actually, I'm not quite sure how spi_pump_messages can be called from an
>> atomic context.
>
> spi_pump_messages() is not called from atomic context. Rather,
> atmel_spi_transfer_one_message() does a spin_lock_irqsave() (via
> atmel_spi_lock()) and then calls atmel_spi_one_transfer(), which calls
> wait_for_completion_timeout(). That's why schedule is being called
> from atomic context. This was introduced by 8090d6d1a4 ("spi: atmel:
> Refactor spi-atmel to use SPI framework queue"). I think you should
> see the warning with CONFIG_PREEMPT=y.
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [BUG] atmel: spi: scheduling while atomic
2014-03-10 8:11 ` Jiří Prchal
@ 2014-03-10 9:08 ` Yang, Wenyou
2014-03-11 9:45 ` Jiří Prchal
0 siblings, 1 reply; 11+ messages in thread
From: Yang, Wenyou @ 2014-03-10 9:08 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Ji?? Prchal [mailto:jiri.prchal at aksignal.cz]
> Sent: Monday, March 10, 2014 4:12 PM
> To: Rabin Vincent; Alexandre Belloni; Yang, Wenyou
> Cc: Ferre, Nicolas; linux-arm-kernel at lists.infradead.org;
> sboyd at codeaurora.org
> Subject: Re: [BUG] atmel: spi: scheduling while atomic
>
> Hi all,
> at first: warning is on all spi devices.
> at second: its with CONFIG_PREEMPT=y, without (# CONFIG_PREEMPT_RCU is
> not set) is OK, but I wonder if this config will be fast enough for our
> usage (nearly RT)?
>
>
> Dne 8.3.2014 01:41, Rabin Vincent napsal(a):
> > 2014-03-07 23:58 GMT+01:00 Alexandre Belloni
> > <alexandre.belloni@free-electrons.com>:
> >> On 05/03/2014 at 07:56:04 +0100, Ji?? Prchal wrote :
> >>> [ 0.902343] BUG: scheduling while atomic: spi0/383/0x00000002
> >>> [ 0.906250] Modules linked in:
> >>> [ 0.906250] CPU: 0 PID: 383 Comm: spi0 Not tainted 3.14.0-
> rc4_cpm9g25+ #1
> >>> [ 0.906250] [<c000d9f4>] (unwind_backtrace) from [<c000bdc0>]
> (show_stack+0x10/0x14)
> >>> [ 0.906250] [<c000bdc0>] (show_stack) from [<c003a224>]
> (__schedule_bug+0x48/0x60)
> >>> [ 0.906250] [<c003a224>] (__schedule_bug) from [<c0390294>]
> (__schedule+0x60/0x484)
> >>> [ 0.906250] [<c0390294>] (__schedule) from [<c038feac>]
> (schedule_timeout+0x17c/0x1ac)
> >>> [ 0.906250] [<c038feac>] (schedule_timeout) from [<c039111c>]
> (wait_for_common+0x10c/0x1f0)
> >>> [ 0.906250] [<c039111c>] (wait_for_common) from [<c0249228>]
> (atmel_spi_transfer_one_message+0x71c/0xa48)
> >>> [ 0.906250] [<c0249228>] (atmel_spi_transfer_one_message) from
> [<c0246624>] (spi_pump_messages+0x210/0x238)
> >>> [ 0.906250] [<c0246624>] (spi_pump_messages) from [<c00343d0>]
> (kthread_worker_fn+0x15c/0x1b4)
> >>> [ 0.906250] [<c00343d0>] (kthread_worker_fn) from [<c0034534>]
> (kthread+0xb8/0xcc)
> >>> [ 0.906250] [<c0034534>] (kthread) from [<c0009510>]
> (ret_from_fork+0x14/0x24)
> >>> [ 0.906250] at25 spi0.0: 128 KByte at25 eeprom, pagesize 512
> >>
> >> Actually, I'm not quite sure how spi_pump_messages can be called from
> an
> >> atomic context.
> >
> > spi_pump_messages() is not called from atomic context. Rather,
> > atmel_spi_transfer_one_message() does a spin_lock_irqsave() (via
> > atmel_spi_lock()) and then calls atmel_spi_one_transfer(), which calls
> > wait_for_completion_timeout(). That's why schedule is being called
> > from atomic context. This was introduced by 8090d6d1a4 ("spi: atmel:
> > Refactor spi-atmel to use SPI framework queue"). I think you should
> > see the warning with CONFIG_PREEMPT=y.
> >
Thanks a lot for the report and analysis.
--->8--------
>From ba2dd7aee12cb09b9ef159251859443e1b055669 Mon Sep 17 00:00:00 2001
From: Wenyou Yang <wenyou.yang@atmel.com>
Date: Mon, 10 Mar 2014 16:44:33 +0800
Subject: [PATCH] spi: atmel: fix BUG: scheduling while atomic with
CONFIG_PREEMPT=y
introduced by 8090d6d1a415d3ae1a7208995decfab8f60f4f36
("spi: atmel: Refactor spi-atmel to use SPI framework queue")
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
---
drivers/spi/spi-atmel.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index b0842f7..e05c3f2 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1130,8 +1130,12 @@ static int atmel_spi_one_transfer(struct spi_master *master,
atmel_spi_next_xfer_pio(master, xfer);
}
+ atmel_spi_unlock(as);
+
ret = wait_for_completion_timeout(&as->xfer_completion,
SPI_DMA_TIMEOUT);
+ atmel_spi_lock(as);
+
if (WARN_ON(ret == 0)) {
dev_err(&spi->dev,
"spi trasfer timeout, err %d\n", ret);
--
1.7.9.5
---<8----
This patch should fix this issue.
I know it is not good one, the lock usage in the driver code should be double checked.
Thanks.
Best Regards,
Wenyou Yang.
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [BUG] atmel: spi: scheduling while atomic
2014-03-10 9:08 ` Yang, Wenyou
@ 2014-03-11 9:45 ` Jiří Prchal
2014-03-11 9:54 ` Yang, Wenyou
0 siblings, 1 reply; 11+ messages in thread
From: Jiří Prchal @ 2014-03-11 9:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
patch applied, it helps.
Is this final solution?
Thanks
Dne 10.3.2014 10:08, Yang, Wenyou napsal(a):
>
>
>> -----Original Message-----
>> From: Ji?? Prchal [mailto:jiri.prchal at aksignal.cz]
>> Sent: Monday, March 10, 2014 4:12 PM
>> To: Rabin Vincent; Alexandre Belloni; Yang, Wenyou
>> Cc: Ferre, Nicolas; linux-arm-kernel at lists.infradead.org;
>> sboyd at codeaurora.org
>> Subject: Re: [BUG] atmel: spi: scheduling while atomic
>>
>> Hi all,
>> at first: warning is on all spi devices.
>> at second: its with CONFIG_PREEMPT=y, without (# CONFIG_PREEMPT_RCU is
>> not set) is OK, but I wonder if this config will be fast enough for our
>> usage (nearly RT)?
>>
>>
>> Dne 8.3.2014 01:41, Rabin Vincent napsal(a):
>>> 2014-03-07 23:58 GMT+01:00 Alexandre Belloni
>>> <alexandre.belloni@free-electrons.com>:
>>>> On 05/03/2014 at 07:56:04 +0100, Ji?? Prchal wrote :
>>>>> [ 0.902343] BUG: scheduling while atomic: spi0/383/0x00000002
>>>>> [ 0.906250] Modules linked in:
>>>>> [ 0.906250] CPU: 0 PID: 383 Comm: spi0 Not tainted 3.14.0-
>> rc4_cpm9g25+ #1
>>>>> [ 0.906250] [<c000d9f4>] (unwind_backtrace) from [<c000bdc0>]
>> (show_stack+0x10/0x14)
>>>>> [ 0.906250] [<c000bdc0>] (show_stack) from [<c003a224>]
>> (__schedule_bug+0x48/0x60)
>>>>> [ 0.906250] [<c003a224>] (__schedule_bug) from [<c0390294>]
>> (__schedule+0x60/0x484)
>>>>> [ 0.906250] [<c0390294>] (__schedule) from [<c038feac>]
>> (schedule_timeout+0x17c/0x1ac)
>>>>> [ 0.906250] [<c038feac>] (schedule_timeout) from [<c039111c>]
>> (wait_for_common+0x10c/0x1f0)
>>>>> [ 0.906250] [<c039111c>] (wait_for_common) from [<c0249228>]
>> (atmel_spi_transfer_one_message+0x71c/0xa48)
>>>>> [ 0.906250] [<c0249228>] (atmel_spi_transfer_one_message) from
>> [<c0246624>] (spi_pump_messages+0x210/0x238)
>>>>> [ 0.906250] [<c0246624>] (spi_pump_messages) from [<c00343d0>]
>> (kthread_worker_fn+0x15c/0x1b4)
>>>>> [ 0.906250] [<c00343d0>] (kthread_worker_fn) from [<c0034534>]
>> (kthread+0xb8/0xcc)
>>>>> [ 0.906250] [<c0034534>] (kthread) from [<c0009510>]
>> (ret_from_fork+0x14/0x24)
>>>>> [ 0.906250] at25 spi0.0: 128 KByte at25 eeprom, pagesize 512
>>>>
>>>> Actually, I'm not quite sure how spi_pump_messages can be called from
>> an
>>>> atomic context.
>>>
>>> spi_pump_messages() is not called from atomic context. Rather,
>>> atmel_spi_transfer_one_message() does a spin_lock_irqsave() (via
>>> atmel_spi_lock()) and then calls atmel_spi_one_transfer(), which calls
>>> wait_for_completion_timeout(). That's why schedule is being called
>>> from atomic context. This was introduced by 8090d6d1a4 ("spi: atmel:
>>> Refactor spi-atmel to use SPI framework queue"). I think you should
>>> see the warning with CONFIG_PREEMPT=y.
>>>
>
> Thanks a lot for the report and analysis.
>
> --->8--------
> From ba2dd7aee12cb09b9ef159251859443e1b055669 Mon Sep 17 00:00:00 2001
> From: Wenyou Yang <wenyou.yang@atmel.com>
> Date: Mon, 10 Mar 2014 16:44:33 +0800
> Subject: [PATCH] spi: atmel: fix BUG: scheduling while atomic with
> CONFIG_PREEMPT=y
>
> introduced by 8090d6d1a415d3ae1a7208995decfab8f60f4f36
> ("spi: atmel: Refactor spi-atmel to use SPI framework queue")
>
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
> ---
> drivers/spi/spi-atmel.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index b0842f7..e05c3f2 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -1130,8 +1130,12 @@ static int atmel_spi_one_transfer(struct spi_master *master,
> atmel_spi_next_xfer_pio(master, xfer);
> }
>
> + atmel_spi_unlock(as);
> +
> ret = wait_for_completion_timeout(&as->xfer_completion,
> SPI_DMA_TIMEOUT);
> + atmel_spi_lock(as);
> +
> if (WARN_ON(ret == 0)) {
> dev_err(&spi->dev,
> "spi trasfer timeout, err %d\n", ret);
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [BUG] atmel: spi: scheduling while atomic
2014-03-11 9:45 ` Jiří Prchal
@ 2014-03-11 9:54 ` Yang, Wenyou
2014-03-11 10:01 ` Jiří Prchal
0 siblings, 1 reply; 11+ messages in thread
From: Yang, Wenyou @ 2014-03-11 9:54 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Ji?? Prchal [mailto:jiri.prchal at aksignal.cz]
> Sent: Tuesday, March 11, 2014 5:46 PM
> To: Yang, Wenyou; Rabin Vincent; Alexandre Belloni
> Cc: Ferre, Nicolas; linux-arm-kernel at lists.infradead.org;
> sboyd at codeaurora.org
> Subject: Re: [BUG] atmel: spi: scheduling while atomic
>
> Hi,
> patch applied, it helps.
> Is this final solution?
> Thanks
Thank for your feedback.
There isn't a better solution so far.
Best Regards,
Wenyou Yang
>
> Dne 10.3.2014 10:08, Yang, Wenyou napsal(a):
> >
> >
> >> -----Original Message-----
> >> From: Ji?? Prchal [mailto:jiri.prchal at aksignal.cz]
> >> Sent: Monday, March 10, 2014 4:12 PM
> >> To: Rabin Vincent; Alexandre Belloni; Yang, Wenyou
> >> Cc: Ferre, Nicolas; linux-arm-kernel at lists.infradead.org;
> >> sboyd at codeaurora.org
> >> Subject: Re: [BUG] atmel: spi: scheduling while atomic
> >>
> >> Hi all,
> >> at first: warning is on all spi devices.
> >> at second: its with CONFIG_PREEMPT=y, without (# CONFIG_PREEMPT_RCU
> >> is not set) is OK, but I wonder if this config will be fast enough
> >> for our usage (nearly RT)?
> >>
> >>
> >> Dne 8.3.2014 01:41, Rabin Vincent napsal(a):
> >>> 2014-03-07 23:58 GMT+01:00 Alexandre Belloni
> >>> <alexandre.belloni@free-electrons.com>:
> >>>> On 05/03/2014 at 07:56:04 +0100, Ji?? Prchal wrote :
> >>>>> [ 0.902343] BUG: scheduling while atomic: spi0/383/0x00000002
> >>>>> [ 0.906250] Modules linked in:
> >>>>> [ 0.906250] CPU: 0 PID: 383 Comm: spi0 Not tainted 3.14.0-
> >> rc4_cpm9g25+ #1
> >>>>> [ 0.906250] [<c000d9f4>] (unwind_backtrace) from [<c000bdc0>]
> >> (show_stack+0x10/0x14)
> >>>>> [ 0.906250] [<c000bdc0>] (show_stack) from [<c003a224>]
> >> (__schedule_bug+0x48/0x60)
> >>>>> [ 0.906250] [<c003a224>] (__schedule_bug) from [<c0390294>]
> >> (__schedule+0x60/0x484)
> >>>>> [ 0.906250] [<c0390294>] (__schedule) from [<c038feac>]
> >> (schedule_timeout+0x17c/0x1ac)
> >>>>> [ 0.906250] [<c038feac>] (schedule_timeout) from [<c039111c>]
> >> (wait_for_common+0x10c/0x1f0)
> >>>>> [ 0.906250] [<c039111c>] (wait_for_common) from [<c0249228>]
> >> (atmel_spi_transfer_one_message+0x71c/0xa48)
> >>>>> [ 0.906250] [<c0249228>] (atmel_spi_transfer_one_message) from
> >> [<c0246624>] (spi_pump_messages+0x210/0x238)
> >>>>> [ 0.906250] [<c0246624>] (spi_pump_messages) from [<c00343d0>]
> >> (kthread_worker_fn+0x15c/0x1b4)
> >>>>> [ 0.906250] [<c00343d0>] (kthread_worker_fn) from [<c0034534>]
> >> (kthread+0xb8/0xcc)
> >>>>> [ 0.906250] [<c0034534>] (kthread) from [<c0009510>]
> >> (ret_from_fork+0x14/0x24)
> >>>>> [ 0.906250] at25 spi0.0: 128 KByte at25 eeprom, pagesize 512
> >>>>
> >>>> Actually, I'm not quite sure how spi_pump_messages can be called
> >>>> from
> >> an
> >>>> atomic context.
> >>>
> >>> spi_pump_messages() is not called from atomic context. Rather,
> >>> atmel_spi_transfer_one_message() does a spin_lock_irqsave() (via
> >>> atmel_spi_lock()) and then calls atmel_spi_one_transfer(), which
> >>> calls wait_for_completion_timeout(). That's why schedule is being
> >>> called from atomic context. This was introduced by 8090d6d1a4 ("spi:
> atmel:
> >>> Refactor spi-atmel to use SPI framework queue"). I think you should
> >>> see the warning with CONFIG_PREEMPT=y.
> >>>
> >
> > Thanks a lot for the report and analysis.
> >
> > --->8--------
> > From ba2dd7aee12cb09b9ef159251859443e1b055669 Mon Sep 17 00:00:00
> > 2001
> > From: Wenyou Yang <wenyou.yang@atmel.com>
> > Date: Mon, 10 Mar 2014 16:44:33 +0800
> > Subject: [PATCH] spi: atmel: fix BUG: scheduling while atomic with
> > CONFIG_PREEMPT=y
> >
> > introduced by 8090d6d1a415d3ae1a7208995decfab8f60f4f36
> > ("spi: atmel: Refactor spi-atmel to use SPI framework queue")
> >
> > Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
> > ---
> > drivers/spi/spi-atmel.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c index
> > b0842f7..e05c3f2 100644
> > --- a/drivers/spi/spi-atmel.c
> > +++ b/drivers/spi/spi-atmel.c
> > @@ -1130,8 +1130,12 @@ static int atmel_spi_one_transfer(struct
> spi_master *master,
> > atmel_spi_next_xfer_pio(master, xfer);
> > }
> >
> > + atmel_spi_unlock(as);
> > +
> > ret = wait_for_completion_timeout(&as->xfer_completion,
> > SPI_DMA_TIMEOUT);
> > + atmel_spi_lock(as);
> > +
> > if (WARN_ON(ret == 0)) {
> > dev_err(&spi->dev,
> > "spi trasfer timeout, err %d\n", ret);
> >
^ permalink raw reply [flat|nested] 11+ messages in thread
* [BUG] atmel: spi: scheduling while atomic
2014-03-11 9:54 ` Yang, Wenyou
@ 2014-03-11 10:01 ` Jiří Prchal
0 siblings, 0 replies; 11+ messages in thread
From: Jiří Prchal @ 2014-03-11 10:01 UTC (permalink / raw)
To: linux-arm-kernel
So shouldn't we (you) apply it to mainstream?
Dne 11.3.2014 10:54, Yang, Wenyou napsal(a):
>
>> -----Original Message-----
>> From: Ji?? Prchal [mailto:jiri.prchal at aksignal.cz]
>> Sent: Tuesday, March 11, 2014 5:46 PM
>> To: Yang, Wenyou; Rabin Vincent; Alexandre Belloni
>> Cc: Ferre, Nicolas; linux-arm-kernel at lists.infradead.org;
>> sboyd at codeaurora.org
>> Subject: Re: [BUG] atmel: spi: scheduling while atomic
>>
>> Hi,
>> patch applied, it helps.
>> Is this final solution?
>> Thanks
>
> Thank for your feedback.
> There isn't a better solution so far.
>
> Best Regards,
> Wenyou Yang
>
>>
>> Dne 10.3.2014 10:08, Yang, Wenyou napsal(a):
>>>
>>>
>>>> -----Original Message-----
>>>> From: Ji?? Prchal [mailto:jiri.prchal at aksignal.cz]
>>>> Sent: Monday, March 10, 2014 4:12 PM
>>>> To: Rabin Vincent; Alexandre Belloni; Yang, Wenyou
>>>> Cc: Ferre, Nicolas; linux-arm-kernel at lists.infradead.org;
>>>> sboyd at codeaurora.org
>>>> Subject: Re: [BUG] atmel: spi: scheduling while atomic
>>>>
>>>> Hi all,
>>>> at first: warning is on all spi devices.
>>>> at second: its with CONFIG_PREEMPT=y, without (# CONFIG_PREEMPT_RCU
>>>> is not set) is OK, but I wonder if this config will be fast enough
>>>> for our usage (nearly RT)?
>>>>
>>>>
>>>> Dne 8.3.2014 01:41, Rabin Vincent napsal(a):
>>>>> 2014-03-07 23:58 GMT+01:00 Alexandre Belloni
>>>>> <alexandre.belloni@free-electrons.com>:
>>>>>> On 05/03/2014 at 07:56:04 +0100, Ji?? Prchal wrote :
>>>>>>> [ 0.902343] BUG: scheduling while atomic: spi0/383/0x00000002
>>>>>>> [ 0.906250] Modules linked in:
>>>>>>> [ 0.906250] CPU: 0 PID: 383 Comm: spi0 Not tainted 3.14.0-
>>>> rc4_cpm9g25+ #1
>>>>>>> [ 0.906250] [<c000d9f4>] (unwind_backtrace) from [<c000bdc0>]
>>>> (show_stack+0x10/0x14)
>>>>>>> [ 0.906250] [<c000bdc0>] (show_stack) from [<c003a224>]
>>>> (__schedule_bug+0x48/0x60)
>>>>>>> [ 0.906250] [<c003a224>] (__schedule_bug) from [<c0390294>]
>>>> (__schedule+0x60/0x484)
>>>>>>> [ 0.906250] [<c0390294>] (__schedule) from [<c038feac>]
>>>> (schedule_timeout+0x17c/0x1ac)
>>>>>>> [ 0.906250] [<c038feac>] (schedule_timeout) from [<c039111c>]
>>>> (wait_for_common+0x10c/0x1f0)
>>>>>>> [ 0.906250] [<c039111c>] (wait_for_common) from [<c0249228>]
>>>> (atmel_spi_transfer_one_message+0x71c/0xa48)
>>>>>>> [ 0.906250] [<c0249228>] (atmel_spi_transfer_one_message) from
>>>> [<c0246624>] (spi_pump_messages+0x210/0x238)
>>>>>>> [ 0.906250] [<c0246624>] (spi_pump_messages) from [<c00343d0>]
>>>> (kthread_worker_fn+0x15c/0x1b4)
>>>>>>> [ 0.906250] [<c00343d0>] (kthread_worker_fn) from [<c0034534>]
>>>> (kthread+0xb8/0xcc)
>>>>>>> [ 0.906250] [<c0034534>] (kthread) from [<c0009510>]
>>>> (ret_from_fork+0x14/0x24)
>>>>>>> [ 0.906250] at25 spi0.0: 128 KByte at25 eeprom, pagesize 512
>>>>>>
>>>>>> Actually, I'm not quite sure how spi_pump_messages can be called
>>>>>> from
>>>> an
>>>>>> atomic context.
>>>>>
>>>>> spi_pump_messages() is not called from atomic context. Rather,
>>>>> atmel_spi_transfer_one_message() does a spin_lock_irqsave() (via
>>>>> atmel_spi_lock()) and then calls atmel_spi_one_transfer(), which
>>>>> calls wait_for_completion_timeout(). That's why schedule is being
>>>>> called from atomic context. This was introduced by 8090d6d1a4 ("spi:
>> atmel:
>>>>> Refactor spi-atmel to use SPI framework queue"). I think you should
>>>>> see the warning with CONFIG_PREEMPT=y.
>>>>>
>>>
>>> Thanks a lot for the report and analysis.
>>>
>>> --->8--------
>>> From ba2dd7aee12cb09b9ef159251859443e1b055669 Mon Sep 17 00:00:00
>>> 2001
>>> From: Wenyou Yang <wenyou.yang@atmel.com>
>>> Date: Mon, 10 Mar 2014 16:44:33 +0800
>>> Subject: [PATCH] spi: atmel: fix BUG: scheduling while atomic with
>>> CONFIG_PREEMPT=y
>>>
>>> introduced by 8090d6d1a415d3ae1a7208995decfab8f60f4f36
>>> ("spi: atmel: Refactor spi-atmel to use SPI framework queue")
>>>
>>> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
>>> ---
>>> drivers/spi/spi-atmel.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c index
>>> b0842f7..e05c3f2 100644
>>> --- a/drivers/spi/spi-atmel.c
>>> +++ b/drivers/spi/spi-atmel.c
>>> @@ -1130,8 +1130,12 @@ static int atmel_spi_one_transfer(struct
>> spi_master *master,
>>> atmel_spi_next_xfer_pio(master, xfer);
>>> }
>>>
>>> + atmel_spi_unlock(as);
>>> +
>>> ret = wait_for_completion_timeout(&as->xfer_completion,
>>> SPI_DMA_TIMEOUT);
>>> + atmel_spi_lock(as);
>>> +
>>> if (WARN_ON(ret == 0)) {
>>> dev_err(&spi->dev,
>>> "spi trasfer timeout, err %d\n", ret);
>>>
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-03-11 10:01 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-04 14:29 [BUG] atmel: spi: scheduling while atomic Jiří Prchal
2014-03-04 21:40 ` Alexandre Belloni
2014-03-05 6:56 ` Jiří Prchal
2014-03-07 22:58 ` Alexandre Belloni
2014-03-08 0:41 ` Rabin Vincent
2014-03-10 8:11 ` Jiří Prchal
2014-03-10 9:08 ` Yang, Wenyou
2014-03-11 9:45 ` Jiří Prchal
2014-03-11 9:54 ` Yang, Wenyou
2014-03-11 10:01 ` Jiří Prchal
2014-03-08 0:46 ` Stephen Boyd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).