SPI hangs with new 4.1 RC kernels (when DMA mode is used)

[mhu...@mhughes.org]

I saw that DT overlay support was re-introduced in the recent pre-4.1 kernel drop, and testing was requested ...

I have a prototype cape with a SPI interface that works well with spidev in the 3.14 kernel line, so thought I'd try the new version. The kernel update, dtc install and the existing overlays installed smoothly, and I added a spidev dts overlay without any issues. However, the SPI driver appears to have an issue.

Basically, doing transfers using the user space spidev interface seems to reliably hang as soon as the transfer size causes a switch to DMA mode (160 bytes). This doesn't require a cape at all, just doing any transfer seems to readily reproduce the problem.

The user space program hangs hard, and the spi1 kernel thread hangs as well. Eventually the kernel detects the hang - dmesg output:
[  360.663769] INFO: task spi1:565 blocked for more than 120 seconds.
[  360.670334]       Not tainted 4.1.0-rc6-bone6 #1
[  360.675277] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  360.683573] spi1            D c05e5585     0   565      2 0x00000000
[  360.683680] [<c05e5585>] (__schedule) from [<c05e57b3>] (schedule+0x2f/0x64)
[  360.683732] [<c05e57b3>] (schedule) from [<c05e6e1d>] (schedule_timeout+0x109/0x14c)
[  360.683778] [<c05e6e1d>] (schedule_timeout) from [<c05e5e35>] (wait_for_common+0x5d/0xd0)
[  360.683845] [<c05e5e35>] (wait_for_common) from [<bf99c0d3>] (omap2_mcspi_transfer_one_message+0x706/0xdf4 [spi_omap2_mcspi])
[  360.683922] [<bf99c0d3>] (omap2_mcspi_transfer_one_message [spi_omap2_mcspi]) from [<c041a201>] (__spi_pump_messages+0x275/0x3d0)
[  360.683970] [<c041a201>] (__spi_pump_messages) from [<c00401e1>] (kthread_worker_fn+0x49/0xf4)
[  360.684009] [<c00401e1>] (kthread_worker_fn) from [<c0040327>] (kthread+0x9b/0xb0)
[  360.684055] [<c0040327>] (kthread) from [<c000e601>] (ret_from_fork+0x11/0x30)

This is easily reproduced with dd - a working write at 159 bytes:
root@arm:/home/debian# dd if=/dev/zero of=/dev/spidev1.0 bs=159 count=1
1+0 records in
1+0 records out
159 bytes (159 B) copied, 0.00497733 s, 31.9 kB/s

And a hang at 160 bytes:
root@arm:/home/debian# dd if=/dev/zero of=/dev/spidev1.0 bs=160 count=1
<hangs permanently>

Kernel version:
$ cat /proc/version
Linux version 4.1.0-rc6-bone6 (root@b2-omap5-uevm-2gb) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 Mon Jun 1 21:27:44 UTC 2015

It is fairly obvious in linux/drivers/spi/spi-omap2-mcspi.c::170 "#define DMA_MIN_BYTES 160" that the problem is with DMA mode transfers.

I'm not sure this is the right forum for reporting driver issues like this - if anyone can point me to a more appropriate venue, please feel free ...

Thanks,
--Matt Hughes

[Robert Nelson]

Hi Matt,

Thanks for testing..

What do you have connected?

If it's just free, i wonder if your hitting:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/spi/spi-omap2-mcspi.c?id=3d0763c006f8da1b44a9f5f9a21187f5b8f674f4

Looking at next, just gpio changes..

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/drivers/spi/spi-omap2-mcspi.c?id=refs/tags/next-20150604

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Robert Nelson]

And confirmed.. (nothing connected to mine..)

debian@beaglebone:/sys$ dd if=/dev/zero of=/dev/spidev1.0 bs=159 count=1

1+0 records in
1+0 records out

159 bytes (159 B) copied, 0.000508833 s, 312 kB/s
debian@beaglebone:/sys$ dd if=/dev/zero of=/dev/spidev1.0 bs=160 count=1
^C

it's hung pretty good right now..

[Robert Nelson]

reverting 3d0763c006f8da1b44a9f5f9a21187f5b8f674f4 doesn't fix it here..

[mhu...@mhughes.org]

Yes, I thought initially I might have some contention or signaling issue, but as you found
it hangs with no cape installed.

Unfortunately I'm not set up for cross compiling the kernel at the moment, so it's hard
to bisect where the issue was introduced.

--Matt