Re: 6.8 powerbook g4 radeon driver kernel panic

Anthony Richardby <[email protected]> Mon, 09 Nov 2020 19:39:09 +0000
Newsgroups gmane.os.openbsd.ppc
Message-ID <[email protected]>
On 2020-11-08 22:45:21 +0000 Jonathan Gray <[email protected]> wrote:

> On Sun, Nov 08, 2020 at 03:21:33PM +0000, Anthony Richardby wrote:
>> On 2020-11-08 14:06:00 +0000 Jonathan Gray <[email protected]> wrote:
>
>>> On Sun, Nov 08, 2020 at 01:09:40PM +0000, Anthony Richardby wrote:
>>> > On 2020-11-08 11:14:50 +0000 Jonathan Gray <[email protected]> wrote:
>>> > > > On Sun, Nov 08, 2020 at 10:51:11AM +0000, Anthony Richardby
>>> wrote:
>>> > > > On 2020-11-08 02:40:26 +0000 Jonathan Gray <[email protected]>
>>> wrote:
>>> > > > > > On Sat, Nov 07, 2020 at 04:01:34PM +0000, Anthony
>>> Richardby
>>> > > wrote:
>>> > > > > > Hey,
>>> > > > > > I'm experiencing a kernel panic whenever I run glxgears,
>>> or it
>>> > > > > would
>>> > > > > > seem when I try to run other gpu-related tasks. I first
>>> > > noticed
>>> > > > > this
>>> > > > > > when playing video via the application 'mpv', after a
>>> couple
>>> > > of
>>> > > > > > seconds of video the system freezes!! I've got the trace
>>> > > output
>>> > > > > for
>>> > > > > > that as the time delay allows me to switch out of X11 to a
>>> > > console
>>> > > > > > before the system crashes. Anyway after this I tried
>>> > > 'glxgears'
>>> > > > > and
>>> > > > > > that crashes immediately (so I'm unable to get the trace,
>>> but
>>> > > it
>>> > > > > > sounds like it's related?).
>>> > > > > > > Just wondering if anyone else is able to reproduce this
>>> on
>>> > > their
>>> > > > > > powerbooks / other g4 macs, does glxgears work for you?
>>> > > > > > > Pic of the trace output: https://postimg.cc/wRLGLKdF
>>> > > > > > What is the actual panic message?
>>> > > > > > For the archives the trace was:
>>> > > > > > panic(b6ae0c) at panic+0x154
>>> > > > > mtx_enter(0) at mtx_enter+0x8c
>>> > > > > drm_update_vblank_count(2a0fcdf8,e000a000,b6ae78) at
>>> > > > > drm_update_vblank_count+0x4b8
>>> > > > > drm_handle_vblank(2000611,82720e) at drm_handle_vblank+0xd8
>>> > > > > r100_irq_process(a19ca0) at r100_irq_process+0x110
>>> > > > > radeon_driver_irq_handler_kms(0) at
>>> > > > > radeon_driver_irq_handler_kms+0x28
>>> > > > > openpic_ext_intr() at openpic_ext_intr+0x274
>>> > > > > extint_call() at extint_call
>>> > > > > --- interrupt ---
>>> > > > > at 0xe7055e1c
>>> > > > > drm_wait_vblank_ioctl(e0732f00,e06b9b84,e7055c60) at
>>> > > > > drm_wait_vblank_ioctl+0xb2
>>> > > > > drm_do_ioctl(251571d0) at drm_do_ioctl+0x298
>>> > > > > drmioctl(25157100,e7055ca8,990000,c010643a,3a033428) at
>>> > > > > drmioctl+0xbc
>>> > > > > > >
>>> > > > The panic message is:
>>> > > > panic: mtx 0xe024cc50: locking against myself
>>> > > > > I forgot to mention that this is new in 6.8, I can run
>>> > > glxgears/play
>>> > > > video with mpv fine using 6.7.
>>> > > > The seqlock is used from an interrupt context
>>> > > drm_update_vblank_count() -> store_vblank()
>>> > > > Can you try a kernel with the following diff?
>>> > > Patch against 6.8 branch.
>>> > > > Index: sys/dev/pci/drm/drm_vblank.c
>>> > >
>>> ===================================================================
>>> > > RCS file: /cvs/src/sys/dev/pci/drm/drm_vblank.c,v
>>> > > retrieving revision 1.6
>>> > > diff -u -p -r1.6 drm_vblank.c
>>> > > --- sys/dev/pci/drm/drm_vblank.c	29 Jul 2020 09:52:21 -0000	1.6
>>> > > +++ sys/dev/pci/drm/drm_vblank.c	8 Nov 2020 11:04:58 -0000
>>> > > @@ -481,7 +481,7 @@ int drm_vblank_init(struct drm_device *d
>>> > > 		init_waitqueue_head(&vblank->queue);
>>> > > 		setup_timer(&vblank->disable_timer, vblank_disable_fn,
>>> > > 		    (unsigned long)vblank);
>>> > > -		seqlock_init(&vblank->seqlock, IPL_NONE);
>>> > > +		seqlock_init(&vblank->seqlock, IPL_TTY);
>>> > > 	}
>>> > > > 	DRM_INFO("Supports vblank timestamp caching Rev 2
>>> > > (21.10.2013).\n");
>>> > > >
>>> > Thanks for the time taken to look into this and offer this diff!
>>> > Unfortunately its still crashing, the trace and panic message
>>> look to
>>> > be the same:
>>> > > https://postimg.cc/G4KNQ9c6
>>> > I've managed to use ports clang and lldb to build and inspect a
>>> powerpc
>>> drm_vblank.o and it points to
>>> src/sys/dev/pci/drm/include/linux/atomic.h:165:2
>>> which is the ilp32 version of atomic64_read().
>>> > The following patch makes sure the lock involved is initialised.
>>> > Index: sys/dev/pci/drm/drm_vblank.c
>>> ===================================================================
>>> RCS file: /cvs/src/sys/dev/pci/drm/drm_vblank.c,v
>>> retrieving revision 1.6
>>> diff -u -p -r1.6 drm_vblank.c
>>> --- sys/dev/pci/drm/drm_vblank.c	29 Jul 2020 09:52:21 -0000	1.6
>>> +++ sys/dev/pci/drm/drm_vblank.c	8 Nov 2020 13:51:27 -0000
>>> @@ -481,7 +481,8 @@ int drm_vblank_init(struct drm_device *d
>>> 		init_waitqueue_head(&vblank->queue);
>>> 		setup_timer(&vblank->disable_timer, vblank_disable_fn,
>>> 		    (unsigned long)vblank);
>>> -		seqlock_init(&vblank->seqlock, IPL_NONE);
>>> +		seqlock_init(&vblank->seqlock, IPL_TTY);
>>> +		atomic64_set(&vblank->count, 0);
>>> 	}
>>> > 	DRM_INFO("Supports vblank timestamp caching Rev 2
>>> (21.10.2013).\n");
>>> > >
>> Absolute rockstar! That looks to have done the trick, I've been
>> watching a video in mpv while running glxgears for a good 10 minutes
>> and everything it's still up and running.
>
>> Many thanks for your help, I'm looking forward to updating my other
>> machine to 6.8 now that this is working.
>
> There are other atomic64 uses where this could come up.
> Can you try this diff to use a single preinitialised mutex?
>
> Index: sys/dev/pci/drm/drm_linux.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/pci/drm/drm_linux.c,v
> retrieving revision 1.63
> diff -u -p -r1.63 drm_linux.c
> --- sys/dev/pci/drm/drm_linux.c	26 Aug 2020 03:29:06 -0000	1.63
> +++ sys/dev/pci/drm/drm_linux.c	8 Nov 2020 22:13:24 -0000
> @@ -67,6 +67,7 @@ tasklet_run(void *arg)
> 	}
> }
>
> +struct mutex atomic64_mtx = MUTEX_INITIALIZER(IPL_HIGH);
> struct mutex sch_mtx = MUTEX_INITIALIZER(IPL_SCHED);
> volatile struct proc *sch_proc;
> volatile void *sch_ident;
> Index: sys/dev/pci/drm/drm_vblank.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/pci/drm/drm_vblank.c,v
> retrieving revision 1.6
> diff -u -p -r1.6 drm_vblank.c
> --- sys/dev/pci/drm/drm_vblank.c	29 Jul 2020 09:52:21 -0000	1.6
> +++ sys/dev/pci/drm/drm_vblank.c	8 Nov 2020 22:13:42 -0000
> @@ -481,7 +481,7 @@ int drm_vblank_init(struct drm_device *d
> 		init_waitqueue_head(&vblank->queue);
> 		setup_timer(&vblank->disable_timer, vblank_disable_fn,
> 		    (unsigned long)vblank);
> -		seqlock_init(&vblank->seqlock, IPL_NONE);
> +		seqlock_init(&vblank->seqlock, IPL_TTY);
> 	}
>
> 	DRM_INFO("Supports vblank timestamp caching Rev 2 (21.10.2013).\n");
> Index: sys/dev/pci/drm/include/linux/atomic.h
> ===================================================================
> RCS file: /cvs/src/sys/dev/pci/drm/include/linux/atomic.h,v
> retrieving revision 1.10
> diff -u -p -r1.10 atomic.h
> --- sys/dev/pci/drm/include/linux/atomic.h	17 Jun 2020 01:03:57
> -0000	1.10
> +++ sys/dev/pci/drm/include/linux/atomic.h	8 Nov 2020 22:12:00 -0000
> @@ -143,18 +143,20 @@ atomic64_xchg(volatile int64_t *v, int64
>
> #else
>
> +extern struct mutex atomic64_mtx;
> +
> typedef struct {
> 	volatile int64_t val;
> -	struct mutex lock;
> } atomic64_t;
>
> -#define ATOMIC64_INIT(x)	{ (x), .lock = MUTEX_INITIALIZER(IPL_HIGH) }
> +#define ATOMIC64_INIT(x)	{ (x) }
>
> static inline void
> atomic64_set(atomic64_t *v, int64_t i)
> {
> -	mtx_init(&v->lock, IPL_HIGH);
> +	mtx_enter(&atomic64_mtx);
> 	v->val = i;
> +	mtx_leave(&atomic64_mtx);
> }
>
> static inline int64_t
> @@ -162,9 +164,9 @@ atomic64_read(atomic64_t *v)
> {
> 	int64_t val;
>
> -	mtx_enter(&v->lock);
> +	mtx_enter(&atomic64_mtx);
> 	val = v->val;
> -	mtx_leave(&v->lock);
> +	mtx_leave(&atomic64_mtx);
>
> 	return val;
> }
> @@ -174,10 +176,10 @@ atomic64_xchg(atomic64_t *v, int64_t n)
> {
> 	int64_t val;
>
> -	mtx_enter(&v->lock);
> +	mtx_enter(&atomic64_mtx);
> 	val = v->val;
> 	v->val = n;
> -	mtx_leave(&v->lock);
> +	mtx_leave(&atomic64_mtx);
>
> 	return val;
> }
> @@ -185,9 +187,9 @@ atomic64_xchg(atomic64_t *v, int64_t n)
> static inline void
> atomic64_add(int i, atomic64_t *v)
> {
> -	mtx_enter(&v->lock);
> +	mtx_enter(&atomic64_mtx);
> 	v->val += i;
> -	mtx_leave(&v->lock);
> +	mtx_leave(&atomic64_mtx);
> }
>
> #define atomic64_inc(p)		atomic64_add(p, 1)
> @@ -197,10 +199,10 @@ atomic64_add_return(int i, atomic64_t *v
> {
> 	int64_t val;
>
> -	mtx_enter(&v->lock);
> +	mtx_enter(&atomic64_mtx);
> 	val = v->val + i;
> 	v->val = val;
> -	mtx_leave(&v->lock);
> +	mtx_leave(&atomic64_mtx);
>
> 	return val;
> }
> @@ -210,9 +212,9 @@ atomic64_add_return(int i, atomic64_t *v
> static inline void
> atomic64_sub(int i, atomic64_t *v)
> {
> -	mtx_enter(&v->lock);
> +	mtx_enter(&atomic64_mtx);
> 	v->val -= i;
> -	mtx_leave(&v->lock);
> +	mtx_leave(&atomic64_mtx);
> }
> #endif
>
>
>
>

I've just given this latest diff a shot.
I'm testing it the same was as I did the last, running a video +
glxgears - and everything looks to be working well.