[Libdlo] defio mmap issues

[justin at dynam.ac]

>> On Mon, Jan 11, 2010 at 6:57 AM, <justin at dynam.ac> wrote:
>>
>>> On a side note, and maybe for a latter email, I'm also getting
>>> horizontal
>>> artifacts on the screen after several hours of operations. Reading the
>>> archives, I saw someone else post on this, and there was a thought
>>> there
>>> was a race condition on the memmap. This is very reproducible for me
>>> (takes about 1 hour though) so if I can provide further info to help
>>> debug
>>> that, I'm willing to take on the challenge!
>>>
>>
>> Here are some datapoints from trying to track down this issue:
>>
>> * The problem happens both with the latest udlfb from git.plugable.com,
>> and
>> with jaya's original defio driver patch posted a few months back. So it
>> could be a problem carried forward, but it doesn't look like a new
>> problem
>> ..
>> * It can be seen more frequently with faster processors and larger
>> screens.
>> On my atom with 1920x1080, it's intermittent and small corruption.  On a
>> faster Celeron with 3 1680x1050 screens, it starts happening quickly
>> with
>> any significant screen activity.
>> * And a fun one: on that multi-screen setup, once you get large areas of
>> the
>> one screen (one DL device) to fail to render ... then moving the mouse
>> and
>> triggering rendering on the *other* DL device/screen, for the
>> corresponding
>> lines on the screen, refreshes the first device/screen properly (!)
>> Since
>> udlfb keeps no shared state between different DisplayLink devices,
>> apparently this confusion is happening at the defio/vma/page table
>> level.
>>
>> Defio is used by several other framebuffer drivers, but perhaps not at
>> these
>> resolutions and not for multiple screens.  Has anyone seen other
>> evidence
>> that would support/contradict this being a general defio problem?  Or
>> perhaps something simple/stupid that udlfb is doing to trigger it?
>>
>> Thanks,
>> Bernie
>>
>
> Hi,
> I did a quick test tonight with fbgrab, to see if a captured screenshot
> also exhibited the same artifacts. It produces a perfectly clear picturem
> so I guess that rules out any problems between application and the
> Virtual(?) Framebuffer.
>
> I've just commented out the backing_buffer code, to see if its got a issue
> there.
>
> Note, this is the first time I've delved into framebuffers and obviously
> defio, I'm just trying what I can to rule out code in a effort to help
> narrow down the possible suspects :) If my effort is wasted, let me know..
> (but its a good learning experience along the way)
>
> Thanks
> justin
>
>

Well,
That failed miserably. Despite the comments in the code that we can
function without a backing_buffer, it oop's my kernel :(