similar to: v4.14.21+: ATOMIC_SLEEP splat bisected to 9428088c90b6 ("drm/qxl: reapply cursor after resetting primary")

On Sun, Jun 17, 2018 at 12:38:06PM +0200, Mike Galbraith wrote: > On Sun, 2018-06-17 at 11:36 +0200, Greg KH wrote: > > > > And if you revert that patch, does everything work again? > > Yes. Great, Dave, care to revert this in 4.18 so I can queue up that revert in older kernels as well? thanks, greg k-h

On Sun, Jun 17, 2018 at 12:38:06PM +0200, Mike Galbraith wrote: > On Sun, 2018-06-17 at 11:36 +0200, Greg KH wrote: > > > > And if you revert that patch, does everything work again? > > Yes. Great, Dave, care to revert this in 4.18 so I can queue up that revert in older kernels as well? thanks, greg k-h

On 17 June 2018 at 21:02, Greg KH <gregkh at linuxfoundation.org> wrote: > On Sun, Jun 17, 2018 at 12:38:06PM +0200, Mike Galbraith wrote: >> On Sun, 2018-06-17 at 11:36 +0200, Greg KH wrote: >> > >> > And if you revert that patch, does everything work again? >> >> Yes. > > Great, Dave, care to revert this in 4.18 so I can queue up that revert

On Sun, 2018-06-17 at 11:36 +0200, Greg KH wrote: > > And if you revert that patch, does everything work again? Yes. -Mike

On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote: > On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith <efault at gmx.de> wrote: > > On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: > >> On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: > >> > > >> > Some display stuff did change for 4.13 for GM20x+ boards. If it's not > >>

On Sun, 2017-12-31 at 13:27 -0500, Ilia Mirkin wrote: > On Tue, Dec 19, 2017 at 8:45 AM, Christian König > <ckoenig.leichtzumerken at gmail.com> wrote: > > Am 19.12.2017 um 11:39 schrieb Michel Dänzer: > >> > >> On 2017-12-19 11:37 AM, Michel Dänzer wrote: > >>> > >>> On 2017-12-18 08:01 PM, Tobias Klausmann wrote: > >>>>

On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: > On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: > > > > Some display stuff did change for 4.13 for GM20x+ boards. If it's not > > too much trouble, a bisect would be pretty useful. > > Bisection seemingly went fine, but the result is odd. > > e98c58e55f68f8785aebfab1f8c9a03d8de0afe1 is the

Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE usage we could convert to WARN_ONCE? Reviewed-By: Karol Herbst <karolherbst at gmail.com> On Fri, Jul 14, 2017 at 5:05 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > On 7/14/17 3:41 PM, Mike Galbraith wrote: >> >> On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote:

On 2017-12-18 08:01 PM, Tobias Klausmann wrote: > On 12/18/17 7:06 PM, Mike Galbraith wrote: >> Greetings, >> >> Kernel bound workloads seem to trigger the below for whatever reason. >>   I only see this when beating up NFS.  There was a kworker wakeup >> latency issue, but with a bandaid applied to fix that up, I can still >> trigger this. > > >

On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote: > On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith <efault at gmx.de> wrote: > > On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: > >> On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: > >> > > >> > Some display stuff did change for 4.13 for GM20x+ boards. If it's not > >>

On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote: >  All DRM did was to slip a > WARN_ON_ONCE() that nouveau triggers into a kernel module where such > things no longer warn, they blow the box out of the water. BTW, turn that irksome WARN_ON_ONCE() in drivers/gpu/drm/drm_vblank.c into a WARN_ONCE(), and all is peachy, you get the warning, box lives. ---

Am 19.12.2017 um 11:39 schrieb Michel Dänzer: > On 2017-12-19 11:37 AM, Michel Dänzer wrote: >> On 2017-12-18 08:01 PM, Tobias Klausmann wrote: >>> On 12/18/17 7:06 PM, Mike Galbraith wrote: >>>> Greetings, >>>> >>>> Kernel bound workloads seem to trigger the below for whatever reason. >>>>   I only see this when beating up NFS.

On Fri, Jul 14, 2017 at 05:58:18PM +0200, Mike Galbraith wrote: > On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote: > > Urgh, is for some mysterious reason the __bug_table section of modules > > ending up in RO memory? > > > > I forever get lost in that link magic :/ > > +1 > > drm.ko >  20

On Fri, Jul 14, 2017 at 03:36:08PM +0200, Mike Galbraith wrote: > Ok, a network outage gave me time to go hunting.  Indeed it is a bad > interaction with the tree DRM merged into.  All DRM did was to slip a > WARN_ON_ONCE() that nouveau triggers into a kernel module where such > things no longer warn, they blow the box out of the water.  I made a > dinky testcase module (attached),

https://bugs.freedesktop.org/show_bug.cgi?id=99921 Bug ID: 99921 Summary: [NVE4] [regression, bisected] 4.10 (atomic): X shows black screen with cursor after monitors turn off Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority:

On Thu, 2018-05-10 at 12:28 +0200, Mike Galbraith wrote: > On Thu, 2018-05-10 at 11:10 +0200, Mike Galbraith wrote: > > Greetings, > > > > When box is earning its keep, nouveau/swiotlb grumble.. a LOT. The > > below is from master.today. > > > > [12594.640959] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes) > > [12594.693000] nouveau

On Fri, Jun 01, 2018 at 04:05:32PM -0400, Jeremy Cline wrote: > "qxl_bo_unref" may sleep, but calling "qxl_release_map" causes > "preempt_disable()" to be called and "preempt_enable()" isn't called > until "qxl_release_unmap" is used. Move the call to "qxl_bo_unref" out > from in between the two to avoid sleeping from an

On 11/21/2017 10:27 AM, Jens Axboe wrote: > On 11/21/2017 03:14 AM, Christian Borntraeger wrote: >> Bisect points to >> >> 1b5a7455d345b223d3a4658a9e5fce985b7998c1 is the first bad commit >> commit 1b5a7455d345b223d3a4658a9e5fce985b7998c1 >> Author: Christoph Hellwig <hch at lst.de> >> Date: Mon Jun 26 12:20:57 2017 +0200 >> >> blk-mq:

On 11/21/2017 10:27 AM, Jens Axboe wrote: > On 11/21/2017 03:14 AM, Christian Borntraeger wrote: >> Bisect points to >> >> 1b5a7455d345b223d3a4658a9e5fce985b7998c1 is the first bad commit >> commit 1b5a7455d345b223d3a4658a9e5fce985b7998c1 >> Author: Christoph Hellwig <hch at lst.de> >> Date: Mon Jun 26 12:20:57 2017 +0200 >> >> blk-mq:

Hi All, First of all, I am not native English speaker. While reading BUILD_VECTOR related code, for example, PPCTargetLowering::LowerBUILD_VECTOR, I see "splat" here and there. Could someone explain what it is (does splat mean the same thing across the whole code base)? Besides, from my English dictionary, I don't know why we call such thing as "splat"... :p Regards,