Hi Tom
On Sat, Sep 7, 2013 at 3:52 PM, David Herrmann dh.herrmann@gmail.com wrote:
Hi
On Sat, Sep 7, 2013 at 3:45 PM, Tom Gundersen teg@jklm.no wrote:
On Sat, Sep 7, 2013 at 2:40 PM, David Herrmann dh.herrmann@gmail.com wrote:
It seems to be unrelated to the x86-sysfb changes. The WARN_ON triggered here obviously means that i915 remaps VMEM before removing efifb. So either i915 now calls ioremap and friends _before_ calling remove_conflicting_framebuffers(), or efifb is not unloaded correctly.
I redid all the tests, and I'm now not able to reproduce this with efifb, only with simplefb (not sure if I made a mistake before or if some config changed). I attached the two different dmesg outputs (only difference is X86_SYSFB).
Tom, some things off the top of my head:
- Is efifb still running after i915 loaded? You can see that via: cat /sys/class/graphics/fb0/name (and also fb1, fb2, ... whatever is there) If it's not running, anymore, then it's quite likely an i915 issue.
I only have /sys/class/graphics/fb0/name and it says inteldrmfb (this is after i915 has taken over from simplefb).
- Do you get a "fb: conflicting hw usage ..." in your dmesg log?
Yes: "fb: conflicting fb hw usage inteldrmfb vs simple - removing generic driver"
Ok, now this makes sense. simplefb lacks the ->fb_destroy() callback so it does not correctly react to remove_conflicting_framebuffer(). But you can safely ignore the warning as simplefb is still unloaded. So it cannot be accessed anymore. It just leaks the remapping.
I will send a patch later today which adds the fb_destroy() callback.
Attached are two patches. The first one should fix this issue, the second one is the rebased ioremap_wc() patch from the other thread.
Does this fix the issue (and the speed-problems)?
Thanks David