* [BUG] atmel: spi: scheduling while atomic @ 2014-03-04 14:29 Jiří Prchal 2014-03-04 21:40 ` Alexandre Belloni 0 siblings, 1 reply; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ messages in thread
* [BUG] atmel: spi: scheduling while atomic @ 2015-09-08 12:17 Jiří Prchal 0 siblings, 0 replies; 12+ messages in thread From: Jiří Prchal @ 2015-09-08 12:17 UTC (permalink / raw) To: Ferre, Nicolas Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A, linux-spi-u79uwXL29TY76Z2rM5mHXA Hi, again I discovered a problem when I access devices on SPI. It appears if I access one device pretty often (about once at second) and the error message appears about 3 times a hour. Nevertheless it works correctly. I thing it's in kernels 3.17 and 3.18 maybe even longer, now I have 3.18.21. ... [10176.960000] BUG: scheduling while atomic: spi0/401/0x00000002 [10176.960000] Modules linked in: [10176.960000] Preemption disabled at:[< (null)>] (null) [10176.960000] [10176.960000] CPU: 0 PID: 401 Comm: spi0 Tainted: G W 3.18.21_cpm9g25 #2 [10176.960000] [<c000eef4>] (unwind_backtrace) from [<c000c558>] (show_stack+0x20/0x24) [10176.960000] [<c000c558>] (show_stack) from [<c04a214c>] (dump_stack+0x20/0x28) [10176.960000] [<c04a214c>] (dump_stack) from [<c049fc74>] (__schedule_bug+0x88/0xac) [10176.960000] [<c049fc74>] (__schedule_bug) from [<c04a3488>] (__schedule+0x68/0x508) [10176.960000] [<c04a3488>] (__schedule) from [<c04a3ae0>] (schedule+0xa0/0xa4) [10176.960000] [<c04a3ae0>] (schedule) from [<c04a3cac>] (schedule_preempt_disabled+0x20/0x2c) [10176.960000] [<c04a3cac>] (schedule_preempt_disabled) from [<c04a5684>] (__mutex_lock_slowpath+0xe8/0x17c) [10176.960000] [<c04a5684>] (__mutex_lock_slowpath) from [<c04a5758>] (mutex_lock+0x40/0x44) [10176.960000] [<c04a5758>] (mutex_lock) from [<c039086c>] (clk_prepare_lock+0x58/0xf4) [10176.960000] [<c039086c>] (clk_prepare_lock) from [<c0391808>] (clk_get_rate+0x1c/0x54) [10176.960000] [<c0391808>] (clk_get_rate) from [<c0311c60>] (atmel_spi_transfer_one_message+0x264/0x9ec) [10176.960000] [<c0311c60>] (atmel_spi_transfer_one_message) from [<c030f428>] (spi_pump_messages+0x5cc/0x5f0) [10176.960000] [<c030f428>] (spi_pump_messages) from [<c003541c>] (kthread_worker_fn+0x140/0x1ac) [10176.960000] [<c003541c>] (kthread_worker_fn) from [<c00355c4>] (kthread+0xd4/0xe8) [10176.960000] [<c00355c4>] (kthread) from [<c0009798>] (ret_from_fork+0x14/0x20) ... -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2015-09-08 12:17 UTC | newest] Thread overview: 12+ 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 -- strict thread matches above, loose matches on Subject: below -- 2015-09-08 12:17 Jiří Prchal
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.