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 On Friday, June 5, 2015 at 9:59:05 AM UTC-7, RobertCNelson wrote: > > On Fri, Jun 5, 2015 at 11:47 AM, Robert Nelson <[email protected] > <javascript:>> wrote: > > On Fri, Jun 5, 2015 at 11:01 AM, <[email protected] <javascript:>> > wrote: > >> 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 > ... > > > > 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, > > 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.. > > Regards, > > -- > Robert Nelson > https://rcn-ee.com/ > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
