search for: unsynchronised

...|chris at chris-wilson.co.uk |nouveau at lists.freedesktop.o | |rg QA Contact|intel-gfx-bugs at lists.freede |xorg-team at lists.x.org |sktop.org | Summary|[dual monitor, xorg, intel] |[prime] unsynchronised |Corrupted rendering |rendering on secondary | |displays Component|Driver/intel |Driver/nouveau -- You are receiving this mail because: You are the assignee for the bug. -------------- next part ----...

https://bugs.freedesktop.org/show_bug.cgi?id=70389 Christopher M. Penalver <christopher.m.penalver at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from

https://bugs.freedesktop.org/show_bug.cgi?id=70389 --- Comment #1 from Kevin Murphy <kemurphy.cmu at gmail.com> --- Also experiencing this on a Thinkpad T530 running Arch with kernel 3.11.6. 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 21f5 Control: I/O+ Mem+

https://bugs.freedesktop.org/show_bug.cgi?id=70389 --- Comment #2 from Ilia Mirkin <imirkin at alum.mit.edu> --- Try updating your intel ddx -- nouveau is not responsible for the contents of the images it renders when in reverse-prime mode -- the primary gpu is (in your case, intel). -- You are receiving this mail because: You are the assignee for the bug. -------------- next part

https://bugs.freedesktop.org/show_bug.cgi?id=70389 Dennis Favro <dfavro at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dfavro at gmail.com --- Comment #3 from Dennis Favro <dfavro at gmail.com> --- Getting what appears to be a

On Thu, Dec 31, 2015 at 09:08:22PM +0200, Michael S. Tsirkin wrote: > +#ifdef CONFIG_SMP > +#define fence() metag_fence() > +#else > +#define fence() do { } while (0) > #endif James, it strikes me as odd that fence() is a no-op instead of a barrier() for UP, can you verify/explain?

On Thu, Dec 31, 2015 at 09:08:22PM +0200, Michael S. Tsirkin wrote: > +#ifdef CONFIG_SMP > +#define fence() metag_fence() > +#else > +#define fence() do { } while (0) > #endif James, it strikes me as odd that fence() is a no-op instead of a barrier() for UP, can you verify/explain?

...with the metag specific __global_lock1() (global voluntary lock between hw threads) whenever a write is performed, and by smp_mb/smp_rmb to try to catch other cases, but I've never been confident this fixes every single corner case, since there could be other places where multiple CPUs perform unsynchronised writes to the same memory location, and expect cache not to become incoherent at that location. It seemed to be sufficient to achieve stability however, and SMP on Meta Linux never made it into a product anyway, since the other hw thread tended to be used for RTOS stuff, so it didn't seem wort...

...ific __global_lock1() (global > voluntary lock between hw threads) whenever a write is performed, and by > smp_mb/smp_rmb to try to catch other cases, but I've never been > confident this fixes every single corner case, since there could be > other places where multiple CPUs perform unsynchronised writes to the > same memory location, and expect cache not to become incoherent at that > location. Ah, yuck, I thought blackfin was the only one attempting !coherent SMP. And yes, this is bound to break in lots of places in subtle ways. We very much assume cache coherency for SMP in generic...

...backup # and when no outside source of synchronized time is available. server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 and noticed that ntpd would fail down to using the undisciplined local clock if I checked with ntpstat. I commented those out, and now ntpstat simply says: unsynchronised time server re-starting polling server every 64 Any idea as to why ntpd -q will sync, but otherwise the clock will not stay in sync even when the local clock drifts by several minutes? It worked fine prior to reboot. Thanks, Ryan