[Bug 229995] [panic, regression] radeonkms "timed sleep before timers are working"
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Mon Jul 23 23:05:06 UTC 2018
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229995
Bug ID: 229995
Summary: [panic, regression] radeonkms "timed sleep before
timers are working"
Product: Base System
Version: 11.2-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: bugs at FreeBSD.org
Reporter: andrew.daugherity at gmail.com
Created attachment 195401
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=195401&action=edit
dmesg w/panic
On a system where I have radeonkms activated via /boot/loader.conf:
kern.vty=vt
radeonkms_load="YES"
radeonkmsfw_R100_cp_load="YES"
This worked properly in 10.2 and 10.3. I recently upgraded to 11.2 and was
greeted by a kernel panic:
====
drmn0: <ATI ES1000 RN50> on vgapci0
info: [drm] RADEON_IS_PCI
[...]
info: [drm] Loading R100 Microcode
info: [drm] radeon: ring at 0x00000000C0001000
info: [drm] ring test succeeded in 2 usecs
panic: timed sleep before timers are working
cpuid = 2
KDB: stack backtrace:
#0 0xffffffff80b3d567 at kdb_backtrace+0x67
#1 0xffffffff80af6b07 at vpanic+0x177
#2 0xffffffff80af6983 at panic+0x43
#3 0xffffffff80b4a363 at sleepq_set_timeout_sbt+0x103
#4 0xffffffff80a96bbc at _cv_timedwait_sbt+0x13c
#5 0xffffffff826e6b05 at radeon_fence_wait_seq+0x1d5
#6 0xffffffff826e68ea at radeon_fence_wait+0x2a
#7 0xffffffff8271e2c2 at r100_ib_test+0x202
#8 0xffffffff826f803a at radeon_ib_ring_tests+0x2a
#9 0xffffffff826e1e61 at radeon_device_init+0x511
#10 0xffffffff826ee443 at radeon_driver_load_kms+0xa3
#11 0xffffffff8289aa06 at drm_get_pci_dev+0x436
#12 0xffffffff8289d6fa at drm_attach_helper+0x13a
#13 0xffffffff826e579f at radeon_attach+0x4f
#14 0xffffffff80b2fc98 at device_attach+0x3b8
#15 0xffffffff80b30f3d at bus_generic_attach+0x3d
#16 0xffffffff8077f0fe at vga_pci_attach+0x3e
#17 0xffffffff80b2fc98 at device_attach+0x3b8
Uptime: 1s
Automatic reboot in 15 seconds - press a key on the console to abort
====
It only panics when loading the module at boot. If I 'kldload radeonkms' after
the system has booted, there is no problem. (So doing that via rc.local is a
workaround at least...)
Note that when the system is up, kldload will automatically load the necessary
firmware modules, but loader(8) will not, hence my specifying
radeonkmsfw_R100_cp_load explicitly. If I leave that line out, the radeonkms
driver will complain about missing firmware, but the system will not panic.
The full dmesg is attached. For comparison, a successful load of radeonkms
after bootup produces mostly the same output up to the "ring test succeeded
message", after which it prints another 30 lines or so:
====
info: [drm] ring test succeeded in 0 usecs
info: [drm] ib test succeeded in 0 usecs
info: [drm] radeon_device_init: Taking over the fictitious range
0xe0000000-0xe4000000
radeon_iicbb0 on drmn0
iicbus0: <Philips I2C bus> on iicbb0 addr 0xff
iic0: <I2C generic I/O> on iicbus0
radeon_iicbb1 on drmn0
iicbus1: <Philips I2C bus> on iicbb1 addr 0xff
iic1: <I2C generic I/O> on iicbus1
radeon_iicbb2 on drmn0
iicbus2: <Philips I2C bus> on iicbb2 addr 0xff
iic2: <I2C generic I/O> on iicbus2
radeon_iicbb3 on drmn0
iicbus3: <Philips I2C bus> on iicbb3 addr 0xff
iic3: <I2C generic I/O> on iicbus3
info: [drm] Radeon Display Connectors
info: [drm] Connector 0:
info: [drm] VGA-1
info: [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
info: [drm] Encoders:
info: [drm] CRT1: INTERNAL_DAC1
info: [drm] Connector VGA-1: get mode from tunables:
info: [drm] - kern.vt.fb.modes.VGA-1
info: [drm] - kern.vt.fb.default_mode
info: [drm] fb mappable at 0xE0040000
info: [drm] vram apper at 0xE0000000
info: [drm] size 2621440
info: [drm] fb depth is 16
info: [drm] pitch is 2560
fbd0 on drmn0
VT: Replacing driver "vga" with new "fb".
====
Workaround:
Comment out any 'radeonkms*_load' lines in /boot/loader.conf and add 'kldload
radeonkms' to /etc/rc.local, to load the driver later in the boot process.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-bugs
mailing list