On Mon, Jan 11, 2010 at 6:57 AM, <<a href="mailto:justin@dynam.ac">justin@dynam.ac</a>> wrote: <div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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! </blockquote><div> Here are some datapoints from trying to track down this issue: * The problem happens both with the latest udlfb from <a href="http://git.plugable.com">git.plugable.com</a>, 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 </div></div>