6.8 powerbook g4 radeon driver kernel panic

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

6.8 powerbook g4 radeon driver kernel panic

Anthony Richardby
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

Cheers,
Anthony.

dmesg on the machine:

[ using 1182236 bytes of bsd ELF symbol table ]
console out [ATY,Jasper_A] console in [keyboard], using USB
using parent ATY,JasperParent:: memaddr b8000000, size 8000000 :
consaddr b8008000 : ioaddr b0020000, size 20000: width 1280 linebytes
1280 height 854 depth 8
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2020 OpenBSD. All rights reserved.
https://www.OpenBSD.org

OpenBSD 6.8 (GENERIC) #790: Mon Oct  5 22:03:32 MDT 2020
     [hidden email]:/usr/src/sys/arch/macppc/compile/GENERIC
real mem = 2147483648 (2048MB)
avail mem = 2071252992 (1975MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root: model PowerBook5,6
cpu0 at mainbus0: 7447A (Revision 0x102): 1666 MHz: 512KB L2 cache
mem0 at mainbus0
spdmem0 at mem0: 1GB DDR SDRAM non-parity PC2700CL2.5
spdmem1 at mem0: 1GB DDR SDRAM non-parity PC2700CL2.5
memc0 at mainbus0: uni-n rev 0xd2
"hw-clock" at memc0 not configured
kiic0 at memc0 offset 0xf8001000
iic0 at kiic0
adt0 at iic0 addr 0x2e: adt7467 rev 0x71
lmtemp0 at iic0 addr 0x49: ds1775
asms0 at iic0 addr 0x58: rev 1.34, version 0.1
mpcpcibr0 at mainbus0 pci: uni-north
pci0 at mpcpcibr0 bus 0
pchb0 at pci0 dev 11 function 0 "Apple UniNorth AGP" rev 0x00
agp at pchb0 not configured
radeondrm0 at pci0 dev 16 function 0 "ATI Radeon Mobility M10" rev 0x00
drm0 at radeondrm0
radeondrm0: irq 48
mpcpcibr1 at mainbus0 pci: uni-north
pci1 at mpcpcibr1 bus 0
macobio0 at pci1 dev 23 function 0 "Apple Intrepid" rev 0x00
openpic0 at macobio0 offset 0x40000: version 0x4614 feature 3f0302 LE
macgpio0 at macobio0 offset 0x50
"modem-reset" at macgpio0 offset 0x1d not configured
"modem-power" at macgpio0 offset 0x1c not configured
"accelerometer-1" at macgpio0 offset 0x13 not configured
"accelerometer-2" at macgpio0 offset 0x14 not configured
"headphone-mute" at macgpio0 offset 0x1f not configured
"amp-mute" at macgpio0 offset 0x20 not configured
"hw-reset" at macgpio0 offset 0x25 not configured
"linein-detect" at macgpio0 offset 0xc not configured
"headphone-detect" at macgpio0 offset 0x17 not configured
dfs0 at macgpio0 offset 0x1b: speeds: 1666, 833 MHz
macgpio1 at macgpio0 offset 0x9: irq 47
"programmer-switch" at macgpio0 offset 0x11 not configured
"gpio4" at macgpio0 offset 0x1e not configured
"escc-legacy" at macobio0 offset 0x12000 not configured
zs0 at macobio0 offset 0x13000: irq 22,23
zstty0 at zs0 channel 0
zstty1 at zs0 channel 1
snapper0 at macobio0 offset 0x0: irq 30,1,2
"timer" at macobio0 offset 0x15000 not configured
adb0 at macobio0 offset 0x16000
apm0 at adb0: battery flags 0x5, 0% charged
piic0 at adb0
iic1 at piic0
"backlight" at macobio0 offset 0xf300 not configured
kiic1 at macobio0 offset 0x18000
iic2 at kiic1
wdc0 at macobio0 offset 0x20000 irq 24: DMA
atapiscsi0 at wdc0 channel 0 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: <MATSHITA, DVD-R UJ-845E, DMP2> removable
cd0(wdc0:0:0): using BIOS timings, DMA mode 2
audio0 at snapper0
bwi0 at pci1 dev 18 function 0 "Broadcom BCM4306" rev 0x03: irq 52,
address 00:11:24:93:24:98
cbb0 at pci1 dev 19 function 0 "TI PCI1510 CardBus" rev 0x00: irq 53
ohci0 at pci1 dev 26 function 0 "Apple Intrepid USB" rev 0x00: irq 29,
version 1.0, legacy support
ohci1 at pci1 dev 27 function 0 "NEC USB" rev 0x43: irq 63, version 1.0
ohci2 at pci1 dev 27 function 1 "NEC USB" rev 0x43: irq 63, version 1.0
ehci0 at pci1 dev 27 function 2 "NEC USB" rev 0x04: irq 63
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "NEC EHCI root hub" rev
2.00/1.00 addr 1
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 1 device 0 cacheline 0x8, lattimer 0x20
pcmcia0 at cardslot0
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "Apple OHCI root hub" rev
1.00/1.00 addr 1
usb2 at ohci1: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "NEC OHCI root hub" rev
1.00/1.00 addr 1
usb3 at ohci2: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "NEC OHCI root hub" rev
1.00/1.00 addr 1
mpcpcibr2 at mainbus0 pci: uni-north
pci2 at mpcpcibr2 bus 0
kauaiata0 at pci2 dev 13 function 0 "Apple Intrepid ATA" rev 0x00
wdc1 at kauaiata0 irq 39: DMA
wd0 at wdc1 channel 0 drive 0: <WDC WD2500BEVE-00WZT0>
wd0: 16-sector PIO, LBA48, 238475MB, 488397168 sectors
wd0(wdc1:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 5
"Apple UniNorth Firewire" rev 0x81 at pci2 dev 14 function 0 not
configured
gem0 at pci2 dev 15 function 0 "Apple Uni-N2 GMAC" rev 0x80: irq 41,
address 00:11:24:80:c6:be
eephy0 at gem0 phy 0: 88E1111 Gigabit PHY, rev. 2
uhidev0 at uhub1 port 1 configuration 1 interface 0 "Apple Computer
HID-proxy" rev 2.00/17.92 addr 2
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes
wskbd0 at ukbd0 mux 1
uhidev1 at uhub1 port 1 configuration 1 interface 1 "Apple Computer
HID-proxy" rev 2.00/17.92 addr 2
uhidev1: iclass 3/1
ums0 at uhidev1: 5 buttons
wsmouse0 at ums0 mux 0
uhidev2 at uhub1 port 2 configuration 1 interface 0 "Apple Computer
Apple Internal Keyboard/Trackpad" rev 2.00/0.28 addr 3
uhidev2: iclass 3/1
ukbd1 at uhidev2: 8 variable keys, 5 key codes, country code 13
wskbd1 at ukbd1: console keyboard
uhidev3 at uhub1 port 2 configuration 1 interface 1 "Apple Computer
Apple Internal Keyboard/Trackpad" rev 2.00/0.28 addr 3
uhidev3: iclass 3/1
utpms0 at uhidev3: Fountain Trackpad
wsmouse1 at utpms0 mux 0
uhidev4 at uhub1 port 2 configuration 1 interface 2 "Apple Computer
Apple Internal Keyboard/Trackpad" rev 2.00/0.28 addr 3
uhidev4: iclass 3/0
uhid0 at uhidev4: input=1, output=0, feature=0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
bootpath: /pci@f4000000/ata-6@d/disk@0:/bsd
root on wd0a (855c18283cfaaad4.a) swap on wd0b dump on wd0b
WARNING: / was not properly unmounted
initializing kernel modesetting (RV350 0x1002:0x4E50 0x1002:0x4E50
0x00).
[drm] *ERROR* Unable to locate a BIOS ROM
radeondrm0: 1280x854, 32bpp
wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using
wskbd1
wskbd0: connecting to wsdisplay0
wsdisplay0: screen 1-5 added (std, vt100 emulation)
uhidev5 at uhub2 port 1 configuration 1 interface 0 "SteelSeries
SteelSeries Rival 110 Gaming Mouse" rev 1.10/0.36 addr 2
uhidev5: iclass 3/0
uhid1 at uhidev5: input=32, output=32, feature=0
uhidev6 at uhub2 port 1 configuration 1 interface 1 "SteelSeries
SteelSeries Rival 110 Gaming Mouse" rev 1.10/0.36 addr 2
uhidev6: iclass 3/1
ums1 at uhidev6: 6 buttons, Z dir
wsmouse2 at ums1 mux 0


Reply | Threaded
Open this post in threaded view
|

Re: 6.8 powerbook g4 radeon driver kernel panic

Jonathan Gray-11
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

Reply | Threaded
Open this post in threaded view
|

Re: 6.8 powerbook g4 radeon driver kernel panic

Anthony Richardby
On 2020-11-08 02:40:26 +0000 Jonathan Gray <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: 6.8 powerbook g4 radeon driver kernel panic

Jonathan Gray-11
On Sun, Nov 08, 2020 at 10:51:11AM +0000, Anthony Richardby wrote:

> On 2020-11-08 02:40:26 +0000 Jonathan Gray <[hidden email]> 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");

Reply | Threaded
Open this post in threaded view
|

Re: 6.8 powerbook g4 radeon driver kernel panic

Anthony Richardby
On 2020-11-08 11:14:50 +0000 Jonathan Gray <[hidden email]> wrote:

> On Sun, Nov 08, 2020 at 10:51:11AM +0000, Anthony Richardby wrote:
>> On 2020-11-08 02:40:26 +0000 Jonathan Gray <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: 6.8 powerbook g4 radeon driver kernel panic

Jonathan Gray-11
On Sun, Nov 08, 2020 at 01:09:40PM +0000, Anthony Richardby wrote:

> On 2020-11-08 11:14:50 +0000 Jonathan Gray <[hidden email]> wrote:
>
> > On Sun, Nov 08, 2020 at 10:51:11AM +0000, Anthony Richardby wrote:
> > > On 2020-11-08 02:40:26 +0000 Jonathan Gray <[hidden email]> 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");

Reply | Threaded
Open this post in threaded view
|

Re: 6.8 powerbook g4 radeon driver kernel panic

Anthony Richardby
On 2020-11-08 14:06:00 +0000 Jonathan Gray <[hidden email]> wrote:

> On Sun, Nov 08, 2020 at 01:09:40PM +0000, Anthony Richardby wrote:
>> On 2020-11-08 11:14:50 +0000 Jonathan Gray <[hidden email]> wrote:
>
>>> On Sun, Nov 08, 2020 at 10:51:11AM +0000, Anthony Richardby wrote:
>>> > On 2020-11-08 02:40:26 +0000 Jonathan Gray <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: 6.8 powerbook g4 radeon driver kernel panic

Jonathan Gray-11
On Sun, Nov 08, 2020 at 03:21:33PM +0000, Anthony Richardby wrote:

> On 2020-11-08 14:06:00 +0000 Jonathan Gray <[hidden email]> wrote:
>
> > On Sun, Nov 08, 2020 at 01:09:40PM +0000, Anthony Richardby wrote:
> > > On 2020-11-08 11:14:50 +0000 Jonathan Gray <[hidden email]> wrote:
> >
> > > > On Sun, Nov 08, 2020 at 10:51:11AM +0000, Anthony Richardby wrote:
> > > > > On 2020-11-08 02:40:26 +0000 Jonathan Gray <[hidden email]> 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
 

Reply | Threaded
Open this post in threaded view
|

Re: 6.8 powerbook g4 radeon driver kernel panic

Anthony Richardby
On 2020-11-08 22:45:21 +0000 Jonathan Gray <[hidden email]> wrote:

> On Sun, Nov 08, 2020 at 03:21:33PM +0000, Anthony Richardby wrote:
>> On 2020-11-08 14:06:00 +0000 Jonathan Gray <[hidden email]> wrote:
>
>>> On Sun, Nov 08, 2020 at 01:09:40PM +0000, Anthony Richardby wrote:
>>> > On 2020-11-08 11:14:50 +0000 Jonathan Gray <[hidden email]> wrote:
>>> > > > On Sun, Nov 08, 2020 at 10:51:11AM +0000, Anthony Richardby
>>> wrote:
>>> > > > On 2020-11-08 02:40:26 +0000 Jonathan Gray <[hidden email]>
>>> 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.

Reply | Threaded
Open this post in threaded view
|

Re: 6.8 powerbook g4 radeon driver kernel panic

Jonathan Gray-11
On Mon, Nov 09, 2020 at 07:39:09PM +0000, Anthony Richardby wrote:

> On 2020-11-08 22:45:21 +0000 Jonathan Gray <[hidden email]> wrote:
>
> > On Sun, Nov 08, 2020 at 03:21:33PM +0000, Anthony Richardby wrote:
> > > On 2020-11-08 14:06:00 +0000 Jonathan Gray <[hidden email]> wrote:
> >
> > > > On Sun, Nov 08, 2020 at 01:09:40PM +0000, Anthony Richardby wrote:
> > > > > On 2020-11-08 11:14:50 +0000 Jonathan Gray <[hidden email]> wrote:
> > > > > > > On Sun, Nov 08, 2020 at 10:51:11AM +0000, Anthony Richardby
> > > > wrote:
> > > > > > > On 2020-11-08 02:40:26 +0000 Jonathan Gray <[hidden email]>
> > > > 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.

Thanks for the report and testing.  I've committed this to -current.