Re: omapdss: Division by zero in kernel
From: Tomi Valkeinen <hidden>
Date: 2015-08-21 09:18:32
Also in:
linux-omap, lkml
On 21/08/15 11:48, Pali Rohár wrote:
On Friday 21 August 2015 11:42:14 Tomi Valkeinen wrote:quoted
On 24/07/15 19:03, Pali Rohár wrote:quoted
Hello, when on N900 (real HW or qemu) I run this command / # echo 0 > /sys/devices/platform/omapdss/overlay0/enabled && echo 0 > /sys/class/graphics/fb0/size then kernel crash with this error message / # [ 29.904113] Division by zero in kernel.Hi! Thanks for explaining.quoted
The problem is that fb console uses the kernel mmapped framebuffer, but omapfb is not aware of the fb console. So the above commands free the framebuffer, as omapfb thinks no one is using it, and then fb console tries to touch the fb.What about refusing those calls from fb console? So fb console will not know about this problem and omapfb will just ignore drawn functions?
Hmm, I'm not sure I understand what you mean... omapfb is not drawing anything, fbcon is doing the drawing independently to the fb. And the fb suddenly disappears without fbcon realizing that.
quoted
omapfb tracks mmaps from userspace, and refuses to free a fb it it's mmapped. I don't know how to fix it straight away. Maybe there's a way for omapfb to check if the fbcon uses the fb in question, and if so, refuses to release/resize the memory. TomiMaemo userspace (on Nokia N900) uses above commands to initialize graphic and Xserver. So it would be nice if disabling framebuffer would work even if fbcon.ko is loaded (or compiled directly into zImage).
Ok. And N900 has fbcon enabled? I wonder how it survives... fbcon can be unbound from userspace with something like: echo 0 > /sys/class/vtconsole/vtcon1/bind After that I think the memory can be freed. But obviously the kernel should not crash here, no question about that. Tomi
Attachments
- signature.asc [application/pgp-signature] 819 bytes