<div dir="ltr"><div> </div><div>I'm pretty sure udlkms handles this already.</div><div> </div><div>Dave. </div></div><div class="gmail_extra"> <div class="gmail_quote">On Wed, Aug 1, 2018 at 11:34 PM, Mikulas Patocka <<a href="mailto:mpatocka@redhat.com" target="_blank">mpatocka@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"> On Wed, 1 Aug 2018, Geert Uytterhoeven wrote: > Hi Mikulas, > > On Wed, Aug 1, 2018 at 12:59 PM Mikulas Patocka <<a href="mailto:mpatocka@redhat.com">mpatocka@redhat.com</a>> wrote: > > On Wed, 1 Aug 2018, Geert Uytterhoeven wrote: > > > On Tue, Jul 31, 2018 at 5:23 PM Mikulas Patocka <<a href="mailto:mpatocka@redhat.com">mpatocka@redhat.com</a>> wrote: > > > > BTW when using the udlfb driver as a console, I've got this warning. > > > > vt_console_print takes a spinlock and then calls the framebuffer driver > > > > that sleeps. > > > > > > > > The question is - whose fault is this? Could the console code somehow be > > > > told to print characters without holding a spinlock? Or does it mean that > > > > framebuffer drivers can't sleep? > > > > > > > > udlfb communicates through USB, so the sleeping is inevitable. > > > > > > > > Mikulas > > > > > > > > > > > > BUG: sleeping function called from invalid context at mm/slab.h:421 > > > > in_atomic(): 1, irqs_disabled(): 0, pid: 430, name: kworker/2:3 > > > > 6 locks held by kworker/2:3/430: > > > > #0: 000000001301127e ( (wq_completion)"events"){....} , at: process_one_work+0x17c/0x3a8 > > > > #1: 00000000beacc951 ( (work_completion)(&(&dlfb->init_framebuffer_work)->work)){....} , at: process_one_work+0x17c/0x3a8 > > > > #2: 00000000a402f826 ( registration_lock){....} , at: register_framebuffer+0x28/0x2c0 [fb] > > > > #3: 0000000021cbe902 ( console_lock){....} , at: register_framebuffer+0x258/0x2c0 [fb] > > > > #4: 0000000096d51735 ( console_owner){....} , at: console_unlock+0x174/0x500 > > > > #5: 00000000faa7f206 ( printing_lock){....} , at: vt_console_print+0x60/0x3a0 > > > > Preemption disabled at: [<ffffff8008403130>] vt_console_print+0x60/0x3a0 > > > > CPU: 2 PID: 430 Comm: kworker/2:3 Not tainted 4.17.10-debug #3 > > > > Hardware name: Marvell Armada 8040 MacchiatoBin/Armada 8040 MacchiatoBin, BIOS EDK II Jul 30 2018 > > > > Workqueue: events dlfb_init_framebuffer_work [udlfb] > > > > Call trace: > > > > dump_backtrace+0x0/0x150 > > > > show_stack+0x14/0x20 > > > > dump_stack+0x8c/0xac > > > > ___might_sleep+0x140/0x170 > > > > __might_sleep+0x50/0x88 > > > > __kmalloc+0x1b0/0x270 > > > > xhci_urb_enqueue+0xa8/0x460 [xhci_hcd] > > > > usb_hcd_submit_urb+0xc0/0x998 [usbcore] > > > > usb_submit_urb+0x1e0/0x518 [usbcore] > > > > dlfb_submit_urb+0x38/0x98 [udlfb] > > > > dlfb_handle_damage.isra.4+0x1e0/0x210 [udlfb] > > > > dlfb_ops_imageblit+0x28/0x38 [udlfb] > > > > soft_cursor+0x15c/0x1d8 [fb] > > > > bit_cursor+0x324/0x510 [fb] > > > > fbcon_cursor+0x144/0x1a0 [fb] > > > > hide_cursor+0x38/0xa0 > > > > vt_console_print+0x334/0x3a0 > > > > console_unlock+0x274/0x500 > > > > register_framebuffer+0x22c/0x2c0 [fb] > > > > dlfb_init_framebuffer_work+0x1ec/0x2fc [udlfb] > > > > process_one_work+0x1e8/0x3a8 > > > > worker_thread+0x44/0x418 > > > > kthread+0x11c/0x120 > > > > ret_from_fork+0x10/0x18 > > > > > > This is sort of expected: you cannot do USB transfers from printk(). > > > > > > Gr{oetje,eeting}s, > > > > > > Geert > > > > So, should there be a framebuffer flag that prevents the console from > > binding to it? > > > > If I start the kernel with "console=ttyS0,115200", it doesn't try to bind > > to the udlfb driver, but if I start it without this flag, it does and > > crashes :-( > > Your frame buffer driver should offload tasks that may sleep to e.g. a > workqueue. > > Gr{oetje,eeting}s, > > Geert </div></div>I can try to do this - but - taking a spinlock and copying 8MB framebuffer would damage scheduling latency even for PCI framebuffer drivers. Mikulas </blockquote></div> </div>