[Bug 209939] New: radeontop causes kernel panic

* [Bug 209939] New: radeontop causes kernel panic
@ 2020-10-29 13:22 bugzilla-daemon
  2020-10-29 13:31 ` [Bug 209939] " bugzilla-daemon
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: bugzilla-daemon @ 2020-10-29 13:22 UTC (permalink / raw)
  To: dri-devel

https://bugzilla.kernel.org/show_bug.cgi?id=209939

            Bug ID: 209939
           Summary: radeontop causes kernel panic
           Product: Drivers
           Version: 2.5
    Kernel Version: 5.9.1
          Hardware: x86-64
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Video(DRI - non Intel)
          Assignee: drivers_video-dri@kernel-bugs.osdl.org
          Reporter: janpieter.sollie@edpnet.be
        Regression: No

Created attachment 293297
  --> https://bugzilla.kernel.org/attachment.cgi?id=293297&action=edit
kernel .config file of 3 PCs

(view 3 .config files)
> PC1: problem pc, Ryzen 2400GE APU with Vega 11 and 5.9.1 kernel (Xorg
> running)
> PC2: working pc, ryzen V1605 APU with vega 8 and 5.8.14 kernel (Xorg running)
> PC3: working pc, Threadripper 1950 + Fiji GPU and 5.9.1 kernel (CLI only)

As the subject states: on PC1, the kernel can't handle the radeontop program,
one way or another, these methods work / do not on PC1:
> - while hardware-accelerated content is running, panic
> - When in console mode, it's fine
> - when switching from console to X, it's fine for a few moments
> - when trying it early (X running sddm, radeontop via ssh), panic

with *panic*, I mean: the PC does not react anymore: the num lock trigger is no
longer working, no input is accepted, the clock on the GUI does not change
anymore, no SSH.

I tried everything:
> - pstore is empty
> - dd if=/dev/kmsg of=/dev/sdb1 & while [ 1]; do echo s > /proc/sysrq-trigger;
> sleep 10; done & radeontop (and pulling it out of this partition afterwards)

The mainboard does not have a RS232 port, so debugging this way is not
possible;
also, I doubt I'd be able to use KDB if the screen stucks at GUI mode ...

If I can do anything to gather more info, let me know

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread