Kernel module crashes (?)

[poglazov]

Not sure about the name so better read further.

I have TFT01-2.2S and I am able to load module and write Hello on display using

echo "Hello" > /dev/tty1

But every time something crashes after about 10 minutes:

[ 132.390000] fbtft_device: SPI devices registered: [ 132.390000] fbtft_device: spidev spi1.0 1000kHz 8 bits mode=0x00 [ 132.400000] fbtft_device: spidev spi1.1 1000kHz 8 bits mode=0x00 [ 132.400000] fbtft_device: spidev spi1.2 1000kHz 8 bits mode=0x00 [ 132.410000] fbtft_device: spi-sc16is7x2 spi1.3 1000kHz 8 bits mode=0x00 [ 132.420000] fbtft_device: spidev spi1.4 1000kHz 8 bits mode=0x00 [ 132.420000] fbtft_device: spidev spi1.5 1000kHz 8 bits mode=0x00 [ 132.430000] fbtft_device: 'fb' Platform devices registered: [ 132.440000] spi spi1.6: gpio index 3, gpio_cs 91 [ 132.500000] fbtft_device: GPIOS used by 'fb_ili9341': [ 132.500000] fbtft_device: 'reset' = GPIO51 [ 132.510000] fbtft_device: 'dc' = GPIO53 [ 132.510000] fbtft_device: SPI devices registered: [ 132.510000] fbtft_device: spidev spi1.0 1000kHz 8 bits mode=0x00 [ 132.520000] fbtft_device: spidev spi1.1 1000kHz 8 bits mode=0x00 [ 132.530000] fbtft_device: spidev spi1.2 1000kHz 8 bits mode=0x00 [ 132.530000] fbtft_device: spi-sc16is7x2 spi1.3 1000kHz 8 bits mode=0x00 [ 132.540000] fbtft_device: spidev spi1.4 1000kHz 8 bits mode=0x00 [ 132.550000] fbtft_device: spidev spi1.5 1000kHz 8 bits mode=0x00 [ 132.560000] fbtft_device: fb_ili9341 spi1.6 20000kHz 8 bits mode=0x00 [ 133.100000] Console: switching to colour frame buffer device 30x20 [ 133.110000] graphics fb0: fb_ili9341 frame buffer, 240x320, 150 KiB video memory, 16 KiB buffer memory, fps=20, spi1.6 at 20 MHz [ 602.080000] [ 602.080000] ====================================================== [ 602.080000] [ INFO: possible circular locking dependency detected ] [ 602.080000] 3.12.0-rc3-imxv5-x0.3 #3 Not tainted [ 602.080000] ------------------------------------------------------- [ 602.080000] kworker/0:1/15 is trying to acquire lock: 602.080000{+.+.+.}, at: [] lock_fb_info+0x18/0x3c [ 602.080000] [ 602.080000] but task is already holding lock: 602.080000{+.+.+.}, at: [] console_callback+0xc/0x12c [ 602.080000] [ 602.080000] which lock already depends on the new lock. [ 602.080000] [ 602.080000] [ 602.080000] the existing dependency chain (in reverse order) is: [ 602.080000] [ 602.080000] -> #1 (console_lock){+.+.+.}: [ 602.080000] [] lock_acquire+0x9c/0x104 [ 602.080000] [] console_lock+0x4c/0x60 [ 602.080000] [] register_framebuffer+0x178/0x264 [ 602.080000] [] fbtft_register_framebuffer+0x1b8/0x2e4 [fbtft] [ 602.080000] [] fbtft_probe_common+0x144/0x2d4 [fbtft] [ 602.080000] [] spi_drv_probe+0x18/0x1c [ 602.080000] [] driver_probe_device+0x104/0x220 [ 602.080000] [] driver_attach+0x94/0x98 [ 602.080000] [] bus_for_each_dev+0x58/0x88 [ 602.080000] [] bus_add_driver+0xd8/0x26c [ 602.080000] [] driver_register+0x78/0xf4 [ 602.080000] [] 0xbf03300c [ 602.080000] [] do_one_initcall+0xe8/0x154 [ 602.080000] [] load_module+0x1a20/0x1f24 [ 602.080000] [] SyS_init_module+0xd8/0xec [ 602.080000] [] ret_fast_syscall+0x0/0x44 [ 602.080000] [ 602.080000] -> #0 (&fb_info->lock){+.+.+.}: [ 602.080000] [] lock_acquire+0x1534/0x1a64 [ 602.080000] [] lock_acquire+0x9c/0x104 [ 602.080000] [] mutex_lock_nested+0x48/0x2d0 [ 602.080000] [] lock_fb_info+0x18/0x3c [ 602.080000] [] fbcon_blank+0x240/0x27c [ 602.080000] [] do_blank_screen+0x1b4/0x270 [ 602.080000] [] console_callback+0x68/0x12c [ 602.080000] [] process_one_work+0x1c0/0x4a4 [ 602.080000] [] worker_thread+0x13c/0x384 [ 602.080000] [] kthread+0xa4/0xb0 [ 602.080000] [] ret_from_fork+0x14/0x34 [ 602.080000] [ 602.080000] other info that might help us debug this: [ 602.080000] [ 602.080000] Possible unsafe locking scenario: [ 602.080000] [ 602.080000] CPU0 CPU1 [ 602.080000] ---- ---- [ 602.080000] lock(console_lock); [ 602.080000] lock(&fb_info->lock); [ 602.080000] lock(console_lock); [ 602.080000] lock(&fb_info->lock); [ 602.080000] [ 602.080000] * DEADLOCK * [ 602.080000] [ 602.080000] 3 locks held by kworker/0:1/15: [ 602.080000] #0: (events){.+.+.+}, at: [] process_one_work+0x134/0x4a4 [ 602.080000] #1: (console_work){+.+...}, at: [] process_one_work+0x134/0x4a4 [ 602.080000] #2: (console_lock){+.+.+.}, at: [] console_callback+0xc/0x12c [ 602.080000] [ 602.080000] stack backtrace: [ 602.080000] CPU: 0 PID: 15 Comm: kworker/0:1 Not tainted 3.12.0-rc3-imxv5-x0.3 #3 [ 602.080000] Workqueue: events console_callback [ 602.080000] from [ 602.080000] from [ 602.080000] from [](lock_acquire+0x1534/0x1a64) [ 602.080000] [](lock_acquire+0x1534/0x1a64) from [ 602.080000] from [ 602.080000] from [ 602.080000] from [ 602.080000] from [ 602.080000] from [ 602.080000] from [ 602.080000] from [ 602.080000] from [ 602.080000] from root@wirenboard:~#

Display goes black but Linux still works good. What's happened and what should I do?

[notro]

Can you test the fbtft driver with another program to see if it is still working? mplayer, fbi, X or something.

[poglazov]

Yep, I was able to view picture after hanging using

root@wirenboard:~# fbi -d /dev/fb0 -T 1 -noverbose -a Mystery-100x100.jpg

Another interesting point I observed - the time of hanging is always the same - [ 602.080000] Second interesting point - when I loaded image using fbi before hanging, hanging doesn't happened at 602.08

[notro]

The problem can be due to a console blanking bug: http://linux-kernel.2935.n7.nabble.com/Deadlock-in-fb-and-tty-td717929.html

As a temporary workaround, you can disable timed console blanking on the kernel command line with 'consoleblank=0'.

I used this google search: https://www.google.no/search?q=deadlock+lock_fb_info+console_callback

I see you are using rc3, maybe it is solved if you use the latest 3.12?

[poglazov]

Notro, you are a man! You advice works like a charm.

Could you please also give me short explanation why this bug (which is obviously not in fbtft) shows only after loading fbtft-related modules? Why does it occur when I just load modules and do nothing after it but doesn't happen when I execute fbi after loading modules?

[notro]

Could you please also give me short explanation why this bug (which is obviously not in fbtft) shows only after loading fbtft-related modules?

I don't think it has anything to do with fbtft per se, but when the graphics driver is loaded, the console is enabled:

[ 133.100000] Console: switching to colour frame buffer device 30x20

The console is connected to a dummy device before the driver is loaded:

Console: colour dummy device 80x30

Why does it occur when I just load modules and do nothing after it but doesn't happen when I execute fbi after loading modules?

As you have confirmed this is related to console blanking, maybe blanking is prevented when fbi is running?

[poglazov]

notro, thanks a lot!