search for: drm_calc_vbltimestamp_from_scanoutpos

...39f7910] report_bug at ffffffff81672248 > #8 [ffffc900039f7938] fixup_bug at ffffffff8101af85 > #9 [ffffc900039f7950] do_trap at ffffffff8101b0d9 > #10 [ffffc900039f79a0] do_error_trap at ffffffff8101b190 > #11 [ffffc900039f7a50] invalid_op at ffffffff8169063e > [exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335] > RIP: ffffffffa020af0f RSP: ffffc900039f7b00 RFLAGS: 00010086 > RAX: ffffffffa04fa100 RBX: ffff8803f9550800 RCX: 0000000000000001 > RDX: ffffffffa0228a58 RSI: 0000000000000001 RDI: ffffffffa022321b > RBP: ffffc900039f7b80 R8: 0000000000000000 R9: ffffffff...

...SS: 0018 #7 [ffffc900039f7910] report_bug at ffffffff81672248 #8 [ffffc900039f7938] fixup_bug at ffffffff8101af85 #9 [ffffc900039f7950] do_trap at ffffffff8101b0d9 #10 [ffffc900039f79a0] do_error_trap at ffffffff8101b190 #11 [ffffc900039f7a50] invalid_op at ffffffff8169063e [exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335] RIP: ffffffffa020af0f RSP: ffffc900039f7b00 RFLAGS: 00010086 RAX: ffffffffa04fa100 RBX: ffff8803f9550800 RCX: 0000000000000001 RDX: ffffffffa0228a58 RSI: 0000000000000001 RDI: ffffffffa022321b RBP: ffffc900039f7b80 R8: 0000000000000000 R9: ffffffffa020adc0 R10: ff...

...new callback get_scanout_position() reads the current location of the scanout process. The operation is currently located in struct drm_driver, but really belongs to the CRTC. Drivers will be converted in separate patches. To help with the conversion, the timestamp calculation has been moved from drm_calc_vbltimestamp_from_scanoutpos() to drm_crtc_vblank_helper_get_vblank_timestamp_internal(). The helper function supports the new and old interface of get_scanout_position(). drm_calc_vbltimestamp_from_scanoutpos() remains as a wrapper around the new function. Callback functions return the scanout position from the CRTC. The leg...

...new callback get_scanout_position() reads the current location of the scanout process. The operation is currently located in struct drm_driver, but really belongs to the CRTC. Drivers will be converted in separate patches. To help with the conversion, the timestamp calculation has been moved from drm_calc_vbltimestamp_from_scanoutpos() to drm_crtc_vblank_helper_get_vblank_timestamp_internal(). The helper function supports the new and old interface of get_scanout_position(). drm_calc_vbltimestamp_from_scanoutpos() remains as a wrapper around the new function. Callback functions return the scanout position from the CRTC. The leg...

The callback get_vblank_timestamp() is currently located in struct drm_driver, but really belongs into struct drm_crtc_funcs. Add an equivalent there. Driver will be converted in separate patches. The default implementation is drm_calc_vbltimestamp_from_scanoutpos(). The patch adds drm_crtc_vblank_helper_get_vblank_timestamp(), which is an implementation for the CRTC callback. v3: * use refactored timestamp calculation to minimize duplicated code * do more checks for crtc != NULL to support legacy drivers v2: * rename helper to drm_crtc_vblank_helper_get...

On Tue, Jul 11, 2017 at 2:08 PM, Mike Galbraith <efault at gmx.de> wrote: > On Tue, 2017-07-11 at 13:51 -0400, Ilia Mirkin wrote: >> Some details that may be useful in analysis of the bug: >> >> 1. lspci -nn -d 10de: > > 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce GTX 980] [10de:13c0] (rev a1) > 01:00.1 Audio device [0403]: NVIDIA

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 >> > too much trouble, a bisect would be pretty useful. >> >> Bisection

On 7/12/17 7:19 PM, Mike Galbraith wrote: > 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

On 7/14/17 3:41 PM, Mike Galbraith wrote: > 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

On Fri, Jul 14, 2017 at 11:15 AM, Mike Galbraith <efault at gmx.de> wrote: > On Fri, 2017-07-14 at 17:10 +0200, Karol Herbst wrote: >> Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE >> usage we could convert to WARN_ONCE? > > Shooting the messenger is generally considered uncool :) That's never stopped it from being a popular practice...

The conversion is a nice catch, but i'd like to have a bit more context, see below! With a better description: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> On 7/14/17 5:10 PM, Karol Herbst wrote: > 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

On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote: > 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,

On Fri, 2017-07-14 at 14:42 -0500, Josh Poimboeuf wrote: > > Does this fix it? Yup, both READONLY __bug_table and "extra stern" warning are gone. > diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h > index 39e702d..aa6b202 100644 > --- a/arch/x86/include/asm/bug.h > +++ b/arch/x86/include/asm/bug.h > @@ -35,7 +35,7 @@ > #define

+++ Peter Zijlstra [14/07/17 18:10 +0200]: >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

On Fri, Jul 14, 2017 at 11:19 AM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > The conversion is a nice catch, but i'd like to have a bit more context, see > below! > > With a better description: > > Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> I don't think it was meant as a serious patch. WARN_ON_ONCE should work. The

On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: > > OK, thanks. So in other words, a fairly standard desktop with a PCIe > board plugged in. No funny business. (Laptops can create a ton of > additional weirdness, which I assumed you had since you were talking > about STR.) Yup, garden variety deskside box. > My best guess is that gf119_head_vblank_put either has a bogus

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 first bad commit -Mike

On Fri, Jul 14, 2017 at 06:33:01PM +0200, Mike Galbraith wrote: > On Fri, 2017-07-14 at 18:10 +0200, Peter Zijlstra wrote: > > 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

On Fri, 2017-07-14 at 17:10 +0200, Karol Herbst wrote: > Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE > usage we could convert to WARN_ONCE? Shooting the messenger is generally considered uncool :) -Mike

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),