loading drm crashes system
Scott Bennett
bennett at sdf.org
Fri Jan 29 00:27:29 UTC 2021
Warner Losh <imp at bsdimp.com> wrote:
> On Mon, Jan 25, 2021 at 11:16 AM Scott Bennett via freebsd-x11 <
> freebsd-x11 at freebsd.org> wrote:
>
> > Robert Huff <roberthuff at rcn.com> wrote:
> >
> > > On a system now running:
> > >
> > > 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-d6327ae8c1: Sun Jan 24
> > > 14:16:54 EST 2021 amd64
> > >
> > > (src+ports updated at midnight US EST)
> > > with PORTS_MODULES="drm-current-kmod gpu-firmware-kmod", starting
> > > the system _without_ loading drm results in a usable system.
> > > Loading drm - whether via kldlist in rc.conf or by kldload at the
> > > console immediately after start-up - instantly crashes the system; the
> > > screen goes blank and the lights on the monitor report no signal
> > > from the system.
> > > There is nothing in dmesg.boot.
> > > In messages I find (75 lines follow):
> > >
> > > Jan 24 17:35:22 jerusalem kernel: [drm:drm_core_init] Initialized
> > > Jan 24 17:35:22 jerusalem kernel: [drm] radeon kernel modesetting
> > enabled.
> > > Jan 24 17:35:22 jerusalem kernel: drmn0: <drmn> on vgapci0
> > > Jan 24 17:35:22 jerusalem kernel: vgapci0: child drmn0 requested
> > pci_enable_io
> > > Jan 24 17:35:22 jerusalem kernel: [drm:drm_minor_register]
> > > Jan 24 17:35:22 jerusalem kernel: [drm:drm_minor_register] new minor
> > registered 128
> > > Jan 24 17:35:22 jerusalem kernel: [drm:drm_minor_register]
> > > Jan 24 17:35:22 jerusalem kernel: [drm:drm_minor_register] new minor
> > registered 0
> > > Jan 24 17:35:22 jerusalem kernel: [drm] initializing kernel modesetting
> > (RS780 0x1002:0x9614 0x1849:0x9614 0x00).
> > > Jan 24 17:35:22 jerusalem kernel: [drm:radeon_get_bios] ATOMBIOS detected
> > > Jan 24 17:35:22 jerusalem kernel: [drm ERROR :radeon_atombios_init]
> > Unable to find PCI I/O BAR; using MMIO for ATOM IIO
> > > Jan 24 17:35:22 jerusalem kernel: [drm:atom_allocate_fb_scratch] atom
> > firmware requested 17ffb000 20kb
> > > Jan 24 17:35:22 jerusalem kernel: drmn0: VRAM: 384M 0x00000000C0000000 -
> > 0x00000000D7FFFFFF (384M used)
> > > Jan 24 17:35:22 jerusalem kernel: drmn0: GTT: 512M 0x00000000A0000000 -
> > 0x00000000BFFFFFFF
> > > Jan 24 17:35:22 jerusalem kernel: [drm] Detected VRAM RAM=384M, BAR=256M
> > > Jan 24 17:35:22 jerusalem kernel: [drm] RAM width 32bits DDR
> > > Jan 24 17:35:22 jerusalem kernel: [drm] radeon: 384M of VRAM memory ready
> > > Jan 24 17:35:22 jerusalem kernel: [drm] radeon: 512M of GTT memory ready.
> > > Jan 24 17:35:22 jerusalem kernel: [drm:r600_init_microcode]
> > > Jan 24 17:35:22 jerusalem kernel: [drm] Loading RS780 Microcode
> > > Jan 24 17:35:23 jerusalem kernel: drmn0: fail (0) to get firmware image
> > with name: radeon/RS780_pfp.bin
> > > Jan 24 17:35:23 jerusalem kernel: drmn0: successfully loaded firmware
> > image with mapped name: radeon_RS780_pfp_bin
> > > Jan 24 17:35:23 jerusalem kernel: drmn0: fail (0) to get firmware image
> > with name: radeon/RS780_me.bin
> > > Jan 24 17:35:23 jerusalem kernel: drmn0: successfully loaded firmware
> > image with mapped name: radeon_RS780_me_bin
> > > Jan 24 17:35:24 jerusalem kernel: drmn0: fail (0) to get firmware image
> > with name: radeon/R600_rlc.bin
> > > Jan 24 17:35:24 jerusalem kernel: drmn0: successfully loaded firmware
> > image with mapped name: radeon_R600_rlc_bin
> > > Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] 3 Power
> > State(s)
> > > Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] State 0:
> > > Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states]
> > Default[drm:radeon_pm_print_states] 1 Clock Mode(s)
> > > Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states]
> > 0 e: 800000
> > > Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] State 1:
> > Performance
> > > Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] 1
> > Clock Mode(s)
> > > Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states]
> > 0 e: 500000
> > > Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] State 2:
> > > Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states] 1
> > Clock Mode(s)
> > > Jan 24 17:35:24 jerusalem kernel: [drm:radeon_pm_print_states]
> > 0 e: 500000
> > > Jan 24 17:35:24 jerusalem kernel: [drm] radeon: power management
> > initialized
> > > Jan 24 17:35:24 jerusalem kernel: drmn0: fail (0) to get firmware image
> > with name: radeon/RS780_uvd.bin
> > > Jan 24 17:35:24 jerusalem kernel: drmn0: successfully loaded firmware
> > image with mapped name: radeon_RS780_uvd_bin
> > > Jan 24 17:35:24 jerusalem kernel: [drm] GART: num cpu pages 131072, num
> > gpu pages 131072
> > > Jan 24 17:35:34 jerusalem kernel: [drm] PCIE GART of 512M enabled (table
> > at 0x00000000C0146000).
> > > Jan 24 17:35:34 jerusalem kernel: drmn0: WB enabled
> > > Jan 24 17:35:34 jerusalem kernel: drmn0: fence driver on ring 0 use gpu
> > addr 0x00000000a0000c00 and cpu addr 0x0xfffff801cb29cc00
> > > Jan 24 17:35:34 jerusalem kernel: drmn0: fence driver on ring 5 use gpu
> > addr 0x00000000c0056038 and cpu addr 0x0xfffff800d0056038
> > > Jan 24 17:35:34 jerusalem kernel: [drm] Supports vblank timestamp
> > caching Rev 2 (21.10.2013).
> > > Jan 24 17:35:34 jerusalem kernel: [drm] Driver supports precise vblank
> > timestamp query.
> > > Jan 24 17:35:34 jerusalem kernel: drmn0: radeon: MSI limited to 32-bit
> > > Jan 24 17:35:34 jerusalem kernel: [drm:drm_irq_install] irq=18
> > > Jan 24 17:35:34 jerusalem kernel: [drm] radeon: irq initialized.
> > > Jan 24 17:35:34 jerusalem kernel: [drm:r600_irq_process]
> > r600_irq_process start: rptr 0, wptr 32
> > > Jan 24 17:35:34 jerusalem kernel: [drm:r600_irq_process] IH: D1 flip
> > > Jan 24 17:35:34 jerusalem kernel: [drm:r600_irq_process] IH: D2 flip
> > > Jan 24 17:35:34 jerusalem kernel: [drm] ring test on 0 succeeded in 1
> > usecs
> > > Jan 24 17:35:34 jerusalem kernel: [drm ERROR :uvd_v1_0_start] UVD not
> > responding, trying to reset the VCPU!!!
> > > Jan 24 17:35:35 jerusalem kernel: [drm ERROR :uvd_v1_0_start] UVD not
> > responding, giving up!!!
> > > Jan 24 17:35:35 jerusalem kernel: drmn0: failed initializing UVD (-1).
> > > Jan 24 17:35:35 jerusalem kernel: [drm:r600_irq_set] r600_irq_set: sw int
> > > Jan 24 17:35:35 jerusalem kernel: [drm] ib test on ring 0 succeeded in 0
> > usecs
> > > Jan 24 17:35:35 jerusalem kernel: [drm:radeon_atombios_get_tv_info]
> > Unknown TV standard; defaulting to NTSC
> > > Jan 24 17:35:35 jerusalem kernel: [drm] Connector VGA-1: get mode from
> > tunables:
> > > Jan 24 17:35:35 jerusalem kernel: [drm] - kern.vt.fb.modes.VGA-1
> > > Jan 24 17:35:35 jerusalem kernel: [drm] - kern.vt.fb.default_mode
> > > Jan 24 17:35:35 jerusalem kernel: [drm:drm_connector_get_cmdline_mode]
> > cmdline mode for connector VGA-1 800x600 at 60Hz
> > > Jan 24 17:35:35 jerusalem kernel: [drm:drm_sysfs_connector_add] adding
> > "VGA-1" to sysfs
> > > Jan 24 17:35:35 jerusalem kernel: [drm:drm_sysfs_hotplug_event]
> > generating hotplug event
> > > Jan 24 17:35:35 jerusalem kernel: [drm] Connector DVI-D-1: get mode from
> > tunables:
> > > Jan 24 17:35:35 jerusalem kernel: [drm] - kern.vt.fb.modes.DVI-D-1
> > > Jan 24 17:35:35 jerusalem kernel: [drm] - kern.vt.fb.default_mode
> > > Jan 24 17:35:35 jerusalem kernel: [drm:drm_connector_get_cmdline_mode]
> > cmdline mode for connector DVI-D-1 800x600 at 60Hz
> > > Jan 24 17:35:35 jerusalem kernel: [drm:drm_sysfs_connector_add] adding
> > "DVI-D-1" to sysfs
> > > Jan 24 17:35:35 jerusalem kernel: [drm:drm_sysfs_hotplug_event]
> > generating hotplug event
> > > Jan 24 17:35:35 jerusalem kernel: [drm] Radeon Display Connectors
> > > Jan 24 17:35:35 jerusalem kernel: [drm] Connector 0:
> > > Jan 24 17:35:35 jerusalem kernel: [drm] VGA-1
> > > Jan 24 17:35:35 jerusalem kernel: [drm] DDC: 0x7e40 0x7e40 0x7e44
> > 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
> > > Jan 24 17:35:35 jerusalem kernel: [drm] Encoders:
> > > Jan 24 17:35:35 jerusalem kernel: [drm] CRT1: INTERNAL_KLDSCP_DAC1
> > > Jan 24 17:35:35 jerusalem kernel: [drm] Connector 1:
> > > Jan 24 17:35:35 jerusalem kernel: [drm] DVI-D-1
> > > Jan 24 17:35:35 jerusalem kernel: [drm] HPD3
> > > Jan 24 17:35:35 jerusalem kernel: [drm] DDC: 0x7e50 0x7e50 0x7e54
> > 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
> > > Jan 24 17:35:35 jerusalem kernel: [drm] Encoders:
> > > Jan 24 17:35:35 jerusalem kernel: [drm] DFP3: INTERNAL_KLDSCP_LVTMA
> > > Jan 24 17:35:35 jerusalem kernel: [drm:r600_irq_set] r600_irq_set: hpd 3
> > > Jan 24 17:35:35 jerusalem kernel: [drm:radeon_atom_encoder_dpms] encoder
> > dpms 21 to mode 3, devices 00000001, active_devices 00000000
> > > Jan 24 17:35:35 jerusalem kernel: [drm:radeon_atom_encoder_dpms] encoder
> > dpms 31 to mode 3, devices 00000200, active_devices 00000000
> > > Jan 24 17:35:35 jerusalem kernel: [drm:drm_crtc_vblank_off] crtc 0,
> > vblank enabled 0, inmodeset 0
> > > Jan 24 17:35:35 jerusalem kernel: [drm:drm_crtc_vblank_off] crtc 1,
> > vblank enabled 0, inmodeset 0
> > > Jan 24 17:35:35 jerusalem kernel: [drm:drm_client_modeset_probe]
> > > Jan 24 17:35:35 jerusalem kernel: [drm:drm_mode_object_get] OBJ ID: 46
> > (2)
> > > Jan 24 17:35:35 jerusalem kernel: [drm:drm_mode_object_get] OBJ ID: 48
> > (2)
> > > Jan 24 17:35:35 jerusalem kernel:
> > [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:46:VGA-1]
> > > Jan 24 17:35:35 jerusalem kernel: [drm] Cannot find any crtc or sizes
> > > Jan 24 17:35:35 jerusalem kernel: [drm] Initialized radeon 2.50.0
> > 20080528 for drmn0 on minor 0
> > > Jan 24 17:35:36 jerusalem kernel: [drm] Cannot find any crtc or sizes
> > >
> > > [insert image of open jaw and glassy-eyed stare]
> > > The GPU is a Radeon HD 3300, and at one point this used to work.
> > > Help, please?
> > >
> > The x11 team's opinion appears to be that a Radeon HD 5770 is too old
> > to be
> > supported, so a Radeon HD 3300, being considerably older, likely falls
> > under that
> > same opinion. See PR #247441.
> >
>
> A big part of the problem is the upstream sources don't support these well
> / anymore. It's not the age, but more that the current code is just broken
> because too few people use it.
>
I might have been willing to buy that explanation, but for the failures of
the graphics team to answer questions like
a) has the GPU hang been reported to the vendor or other upstream party?
We now know of at least two Radeon HD models for which AMD's coders
have broken support. AMD should be informed. Has it been?
b) has the DRM bug that mishandles GPU hangs been reported upstream?
c) if stable branches of FreeBSD are only supported by the graphics team
if kept up to date, then what counts as up to date? only the most
recent commit? The last commit of the previous day? A week back?
A month? Given the time required to do a buildworld and/or
buildkernel, this information is necessary for planning by the user.
d) which Radeon cards are no longer supported and which are still
supported?
That last one is important to those of us despairing of ever having working,
safe-to-use graphics support again in FreeBSD on their systems. If what was
working before has been broken without warning (or, apparently, concern on the
part of the graphics team) and is likely never to work again in the future, then
what should we look to obtain as replacement hardware that is 1) not too new to
work, 2) not too old to work, 3) not too costly for our budgets, and 4) likely
to continue to work long enough to justify the cost before it, too, gets broken
permanently and without warning? We users need some information, some guidelines.
How about if the graphics team were to request that the FreeBSD Foundation
allocate funding to hire some graphics team members, so that it would be more
than just a volunteer effort? Experienced GPU programmers and X.org programmers
could lead the way toward fixing FreeBSD's currently weakest area. A decade ago
the weakest area was clearly the ports/packages area, which has been greatly
improved since that time, but beginning four or five years ago graphics support
for FreeBSD became even weaker than it once was for ports and packages, namely,
it has been recurring, utter chaos. Hiring some dedicated specialists to work
full time might be a way out of the present situation.
Scott
More information about the freebsd-x11
mailing list