Bug 247441 - graphics/gpu-firmware-kmod and or graphics/drm-fbsd11.2-kmod crashing 11.2 to 11.4 with a Radeon HD 5770 card
Summary: graphics/gpu-firmware-kmod and or graphics/drm-fbsd11.2-kmod crashing 11.2 to...
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-x11 (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-20 17:29 UTC by Pau Amma
Modified: 2021-12-23 20:32 UTC (History)
15 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pau Amma 2020-06-20 17:29:41 UTC
[Editor's note: filing this on behalf of Scott Bennett <bennett@sdf.org> who can't file it due to being unable to run X or a GUI browser, as requested by Mark Linimon in IRC.]

     After a random uptime, messages like the following appear in
/var/log/messages.  The next messages to appear are the copyright lines
of the next reboot.

drmn0: ring 0 stalled for more than 10011msec                                                                                                                                                                     
drmn0: GPU lockup (current fence id 0x0000000000029cee last fence id 0x0000000000029d02 on ring 0)                                                                                                                
drmn0: failed to get a new IB (-11)                                                                                                                                                                               
[drm:radeon_cs_ib_fill] Failed to get ib !                                                                                                                                                                        
drmn0: Saved 631 dwords of commands on ring 0.

     drm-fbsd11.2-kmod appears to work beautifully, except for one little
problem.  If xorg is running, then after some random uptime between 3 hours
and 35 hours, the GPU apparently hangs, turning my screen light blue with
very pale blue vertical pinstripes two pixels wide and separated by
somewhere around eight or ten pixels all the way across the screen.  It's
reasonably pretty, but not what I want.  Messages prefixed with "drmn0: "
are placed into /var/log/messages, informing that the GPU is not responding
and sometimes that the system will be rebooted in 10 seconds, is what does
happen every time.  After some seconds have elapsed, the system crashes down
into the BIOS, which goes through a reset and stops, waiting for approval to
continue because one of the fan power connectors on the motherboard is
not currently in use.  An orderly shutdown is *not* done, so I have to pick
up quite a few pieces to get things running again.
     These crashes do not occur as long as I don't run xorg and just use the
default eight virtual consoles, i.e., character mode only.

Example of Xorg.0.log dated 14 December 2019:

[   757.454]
X.Org X Server 1.18.4
Release Date: 2016-07-19
[   757.454] X Protocol Version 11, Revision 0
[   757.454] Build Operating System: FreeBSD 11.3-STABLE amd64
[   757.454] Current Operating System: FreeBSD hellas 11.3-STABLE FreeBSD 11.3-STABLE #19 r355521: Sun Dec  8 14:41:54 CST 2019     bennett@hellas:/usr/obj/usr/src/sys/hellas amd64
[   757.454] Build Date: 22 September 2019  05:11:08PM
[   757.454]  
[   757.454] Current version of pixman: 0.38.4
[   757.454]     Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.
[   757.454] Markers: (--) probed, (**) from config file, (==) default setting,
    (++) from command line, (!!) notice, (II) informational,
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   757.454] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Dec 14 18:25:55 2019
[   757.537] (==) Using config directory: "/usr/local/etc/X11/xorg.conf.d"
[   757.537] (==) Using system config directory "/usr/local/share/X11/xorg.conf.d"
[   757.555] (==) No Layout section.  Using the first Screen section.
[   757.555] (==) No screen section available. Using defaults.
[   757.555] (**) |-->Screen "Default Screen Section" (0)
[   757.555] (**) |   |-->Monitor "<default monitor>"
[   757.557] (==) No monitor specified for screen "Default Screen Section".
    Using a default monitor configuration.
[   757.557] (==) Automatically adding devices
[   757.557] (==) Automatically enabling devices
[   757.557] (==) Not automatically adding GPU devices
[   757.559] (==) Max clients allowed: 256, resource mask: 0x1fffff
[   758.273] (**) FontPath set to:
    /usr/local/share/fonts/100dpi,
    /usr/local/share/fonts/75dpi,
    /usr/local/share/fonts/adobe-cmaps,
    /usr/local/share/fonts/Caladea,
    /usr/local/share/fonts/cantarell,
    /usr/local/share/fonts/Carlito,
    /usr/local/share/fonts/cyrillic,
    /usr/local/share/fonts/dejavu,
    /usr/local/share/fonts/Droid,
    /usr/local/share/fonts/freefont-ttf,
    /usr/local/share/fonts/GentiumBasic,
    /usr/local/share/fonts/GentiumPlus,
    /usr/local/share/fonts/libdockapp,
    /usr/local/share/fonts/Liberation,
    /usr/local/share/fonts/LinLibertineG,
    /usr/local/share/fonts/Lohit,
    /usr/local/share/fonts/misc,
    /usr/local/share/fonts/nanum-ttf,
    /usr/local/share/fonts/OTF,
    /usr/local/share/fonts/stix,
    /usr/local/share/fonts/terminus-font,
    /usr/local/share/fonts/TrueType,
    /usr/local/share/fonts/TTF,
    /usr/local/share/fonts/twemoji-color-font-ttf,
    /usr/local/share/fonts/Type1,
    /usr/local/share/fonts/misc/,
    /usr/local/share/fonts/TTF/,
    /usr/local/share/fonts/OTF/,
    /usr/local/share/fonts/Type1/,
    /usr/local/share/f
[   758.273] (==) ModulePath set to "/usr/local/lib/xorg/modules"
[   758.273] (II) The server relies on devd to provide the list of input devices.
    If no devices become available, reconfigure devd or disable AutoAddDevices.
[   758.273] (II) Loader magic: 0x84ae90
[   758.273] (II) Module ABI versions:
[   758.273]     X.Org ANSI C Emulation: 0.4
[   758.273]     X.Org Video Driver: 20.0
[   758.273]     X.Org XInput driver : 22.1
[   758.273]     X.Org Server Extension : 9.0
[   758.273] (--) PCI:*(0:2:0:0) 1002:68b8:1002:2543 rev 0, Mem @ 0xc0000000/268435456, 0xdfdc0000/131072, I/O @ 0x00009c00/256, BIOS @ 0x????????/65536
[   758.273] (II) LoadModule: "glx"
[   758.275] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so
[   758.791] (II) Module glx: vendor="X.Org Foundation"
[   758.791]     compiled for 1.18.4, module version = 1.0.0
[   758.791]     ABI class: X.Org Server Extension, version 9.0
[   758.791] (==) AIGLX enabled
[   758.791] (==) Matched ati as autoconfigured driver 0
[   758.791] (==) Matched modesetting as autoconfigured driver 1
[   758.791] (==) Matched scfb as autoconfigured driver 2
[   758.791] (==) Matched vesa as autoconfigured driver 3
[   758.791] (==) Assigned the driver to the xf86ConfigLayout
[   758.791] (II) LoadModule: "ati"
[   758.817] (II) Loading /usr/local/lib/xorg/modules/drivers/ati_drv.so
[   758.831] (II) Module ati: vendor="X.Org Foundation"
[   758.831]     compiled for 1.18.4, module version = 19.0.1
[   758.831]     Module class: X.Org Video Driver
[   758.831]     ABI class: X.Org Video Driver, version 20.0
[   758.831] (II) LoadModule: "radeon"
[   758.831] (II) Loading /usr/local/lib/xorg/modules/drivers/radeon_drv.so
[   759.004] (II) Module radeon: vendor="X.Org Foundation"
[   759.004]     compiled for 1.18.4, module version = 19.0.1
[   759.004]     Module class: X.Org Video Driver
[   759.004]     ABI class: X.Org Video Driver, version 20.0
[   759.004] (II) LoadModule: "modesetting"
[   759.004] (II) Loading /usr/local/lib/xorg/modules/drivers/modesetting_drv.so
[   759.080] (II) Module modesetting: vendor="X.Org Foundation"
[   759.080]     compiled for 1.18.4, module version = 1.18.4
[   759.080]     Module class: X.Org Video Driver
[   759.080]     ABI class: X.Org Video Driver, version 20.0
[   759.080] (II) LoadModule: "scfb"
[   759.080] (II) Loading /usr/local/lib/xorg/modules/drivers/scfb_drv.so
[   759.093] (II) Module scfb: vendor="X.Org Foundation"
[   759.093]     compiled for 1.18.4, module version = 0.0.4
[   759.093]     ABI class: X.Org Video Driver, version 20.0
[   759.093] (II) LoadModule: "vesa"
[   759.093] (II) Loading /usr/local/lib/xorg/modules/drivers/vesa_drv.so
[   759.130] (II) Module vesa: vendor="X.Org Foundation"
[   759.130]     compiled for 1.18.4, module version = 2.4.0
[   759.130]     Module class: X.Org Video Driver
[   759.131]     ABI class: X.Org Video Driver, version 20.0
[   759.131] (II) RADEON: Driver for ATI/AMD Radeon chipsets:
    ATI Radeon Mobility X600 (M24), ATI FireMV 2400,
    ATI Radeon Mobility X300 (M24), ATI FireGL M24 GL,
    ATI Radeon X600 (RV380), ATI FireGL V3200 (RV380),
    ATI Radeon IGP320 (A3), ATI Radeon IGP330/340/350 (A4),
    ATI Radeon 9500, ATI Radeon 9600TX, ATI FireGL Z1, ATI Radeon 9800SE,
    ATI Radeon 9800, ATI FireGL X2, ATI Radeon 9600, ATI Radeon 9600SE,
    ATI Radeon 9600XT, ATI FireGL T2, ATI Radeon 9650, ATI FireGL RV360,
    ATI Radeon 7000 IGP (A4+), ATI Radeon 8500 AIW,
    ATI Radeon IGP320M (U1), ATI Radeon IGP330M/340M/350M (U2),
    ATI Radeon Mobility 7000 IGP, ATI Radeon 9000/PRO, ATI Radeon 9000,
    ATI Radeon X800 (R420), ATI Radeon X800PRO (R420),
    ATI Radeon X800SE (R420), ATI FireGL X3 (R420),
    ATI Radeon Mobility 9800 (M18), ATI Radeon X800 SE (R420),
    ATI Radeon X800XT (R420), ATI Radeon X800 VE (R420),
    ATI Radeon X850 (R480), ATI Radeon X850 XT (R480),
    ATI Radeon X850 SE (R480), ATI Radeon X850 PRO (R480),
    ATI Radeon X850 XT PE (R480), ATI Radeon Mobility M7,
    ATI Mobility FireGL 7800 M7, ATI Radeon Mobility M6,
    ATI FireGL Mobility 9000 (M9), ATI Radeon Mobility 9000 (M9),
    ATI Radeon 9700 Pro, ATI Radeon 9700/9500Pro, ATI FireGL X1,
    ATI Radeon 9800PRO, ATI Radeon 9800XT,
    ATI Radeon Mobility 9600/9700 (M10/M11),
    ATI Radeon Mobility 9600 (M10), ATI Radeon Mobility 9600 (M11),
    ATI FireGL Mobility T2 (M10), ATI FireGL Mobility T2e (M11),
    ATI Radeon, ATI FireGL 8700/8800, ATI Radeon 8500, ATI Radeon 9100,
    ATI Radeon 7500, ATI Radeon VE/7000, ATI ES1000,
    ATI Radeon Mobility X300 (M22), ATI Radeon Mobility X600 SE (M24C),
    ATI FireGL M22 GL, ATI Radeon X800 (R423), ATI Radeon X800PRO (R423),
    ATI Radeon X800LE (R423), ATI Radeon X800SE (R423),
    ATI Radeon X800 XTP (R430), ATI Radeon X800 XL (R430),
    ATI Radeon X800 SE (R430), ATI Radeon X800 (R430),
    ATI FireGL V7100 (R423), ATI FireGL V5100 (R423),
    ATI FireGL unknown (R423), ATI Mobility FireGL V5000 (M26),
    ATI Mobility Radeon X700 XL (M26), ATI Mobility Radeon X700 (M26),
    ATI Radeon X550XTX, ATI Radeon 9100 IGP (A5),
    ATI Radeon Mobility 9100 IGP (U3), ATI Radeon XPRESS 200,
    ATI Radeon XPRESS 200M, ATI Radeon 9250, ATI Radeon 9200,
    ATI Radeon 9200SE, ATI FireMV 2200, ATI Radeon X300 (RV370),
    ATI Radeon X600 (RV370), ATI Radeon X550 (RV370),
    ATI FireGL V3100 (RV370), ATI FireMV 2200 PCIE (RV370),
    ATI Radeon Mobility 9200 (M9+), ATI Mobility Radeon X800 XT (M28),
    ATI Mobility FireGL V5100 (M28), ATI Mobility Radeon X800 (M28),
    ATI Radeon X850, ATI unknown Radeon / FireGL (R480),
    ATI Radeon X800XT (R423), ATI FireGL V5000 (RV410),
    ATI Radeon X700 XT (RV410), ATI Radeon X700 PRO (RV410),
    ATI Radeon X700 SE (RV410), ATI Radeon X700 (RV410),
    ATI Radeon X1800, ATI Mobility Radeon X1800 XT,
    ATI Mobility Radeon X1800, ATI Mobility FireGL V7200,
    ATI FireGL V7200, ATI FireGL V5300, ATI Mobility FireGL V7100,
    ATI FireGL V7300, ATI FireGL V7350, ATI Radeon X1600, ATI RV505,
    ATI Radeon X1300/X1550, ATI Radeon X1550, ATI M54-GL,
    ATI Mobility Radeon X1400, ATI Radeon X1550 64-bit,
    ATI Mobility Radeon X1300, ATI Radeon X1300, ATI FireGL V3300,
    ATI FireGL V3350, ATI Mobility Radeon X1450,
    ATI Mobility Radeon X2300, ATI Mobility Radeon X1350,
    ATI FireMV 2250, ATI Radeon X1650, ATI Mobility FireGL V5200,
    ATI Mobility Radeon X1600, ATI Radeon X1300 XT/X1600 Pro,
    ATI FireGL V3400, ATI Mobility FireGL V5250,
    ATI Mobility Radeon X1700, ATI Mobility Radeon X1700 XT,
    ATI FireGL V5200, ATI Radeon X2300HD, ATI Mobility Radeon HD 2300,
    ATI Radeon X1950, ATI Radeon X1900, ATI AMD Stream Processor,
    ATI RV560, ATI Mobility Radeon X1900, ATI Radeon X1950 GT, ATI RV570,
    ATI FireGL V7400, ATI Radeon 9100 PRO IGP,
    ATI Radeon Mobility 9200 IGP, ATI Radeon X1200, ATI RS740,
    ATI RS740M, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 Pro,
    ATI Radeon HD 2900 GT, ATI FireGL V8650, ATI FireGL V8600,
    ATI FireGL V7600, ATI Radeon 4800 Series, ATI Radeon HD 4870 x2,
    ATI Radeon HD 4850 x2, ATI FirePro V8750 (FireGL),
    ATI FirePro V7760 (FireGL), ATI Mobility RADEON HD 4850,
    ATI Mobility RADEON HD 4850 X2, ATI FirePro RV770,
    AMD FireStream 9270, AMD FireStream 9250, ATI FirePro V8700 (FireGL),
    ATI Mobility RADEON HD 4870, ATI Mobility RADEON M98,
    ATI FirePro M7750, ATI M98, ATI Mobility Radeon HD 4650,
    ATI Radeon RV730 (AGP), ATI Mobility Radeon HD 4670,
    ATI FirePro M5750, ATI RV730XT [Radeon HD 4670], ATI RADEON E4600,
    ATI Radeon HD 4600 Series, ATI RV730 PRO [Radeon HD 4650],
    ATI FirePro V7750 (FireGL), ATI FirePro V5700 (FireGL),
    ATI FirePro V3750 (FireGL), ATI Mobility Radeon HD 4830,
    ATI Mobility Radeon HD 4850, ATI FirePro M7740, ATI RV740,
    ATI Radeon HD 4770, ATI Radeon HD 4700 Series, ATI RV610,
    ATI Radeon HD 2400 XT, ATI Radeon HD 2400 Pro,
    ATI Radeon HD 2400 PRO AGP, ATI FireGL V4000, ATI Radeon HD 2350,
    ATI Mobility Radeon HD 2400 XT, ATI Mobility Radeon HD 2400,
    ATI RADEON E2400, ATI FireMV 2260, ATI RV670, ATI Radeon HD3870,
    ATI Mobility Radeon HD 3850, ATI Radeon HD3850,
    ATI Mobility Radeon HD 3850 X2, ATI Mobility Radeon HD 3870,
    ATI Mobility Radeon HD 3870 X2, ATI Radeon HD3870 X2,
    ATI FireGL V7700, ATI Radeon HD3690, AMD Firestream 9170,
    ATI Radeon HD 4550, ATI Radeon RV710, ATI Radeon HD 4350,
    ATI Mobility Radeon 4300 Series, ATI Mobility Radeon 4500 Series,
    ATI FirePro RG220, ATI Mobility Radeon 4330, ATI RV630,
    ATI Mobility Radeon HD 2600, ATI Mobility Radeon HD 2600 XT,
    ATI Radeon HD 2600 XT AGP, ATI Radeon HD 2600 Pro AGP,
    ATI Radeon HD 2600 XT, ATI Radeon HD 2600 Pro, ATI Gemini RV630,
    ATI Gemini Mobility Radeon HD 2600 XT, ATI FireGL V5600,
    ATI FireGL V3600, ATI Radeon HD 2600 LE,
    ATI Mobility FireGL Graphics Processor, ATI Radeon HD 3470,
    ATI Mobility Radeon HD 3430, ATI Mobility Radeon HD 3400 Series,
    ATI Radeon HD 3450, ATI Radeon HD 3430, ATI FirePro V3700,
    ATI FireMV 2450, ATI Radeon HD 3600 Series, ATI Radeon HD 3650 AGP,
    ATI Radeon HD 3600 PRO, ATI Radeon HD 3600 XT,
    ATI Mobility Radeon HD 3650, ATI Mobility Radeon HD 3670,
    ATI Mobility FireGL V5700, ATI Mobility FireGL V5725,
    ATI Radeon HD 3200 Graphics, ATI Radeon 3100 Graphics,
    ATI Radeon HD 3300 Graphics, ATI Radeon 3000 Graphics, SUMO, SUMO2,
    ATI Radeon HD 4200, ATI Radeon 4100, ATI Mobility Radeon HD 4200,
    ATI Mobility Radeon 4100, ATI Radeon HD 4290, ATI Radeon HD 4250,
    AMD Radeon HD 6310 Graphics, AMD Radeon HD 6250 Graphics,
    AMD Radeon HD 6300 Series Graphics,
    AMD Radeon HD 6200 Series Graphics, PALM, CYPRESS,
    ATI FirePro (FireGL) Graphics Adapter, AMD Firestream 9370,
    AMD Firestream 9350, ATI Radeon HD 5800 Series,
    ATI Radeon HD 5900 Series, ATI Mobility Radeon HD 5800 Series,
    ATI Radeon HD 5700 Series, ATI Radeon HD 6700 Series,
    ATI Mobility Radeon HD 5000 Series, ATI Mobility Radeon HD 5570,
    ATI Radeon HD 5670, ATI Radeon HD 5570, ATI Radeon HD 5500 Series,
    REDWOOD, ATI Mobility Radeon Graphics, CEDAR, ATI FirePro 2270,
    ATI Radeon HD 5450, CAYMAN, AMD Radeon HD 6900 Series,
    AMD Radeon HD 6900M Series, Mobility Radeon HD 6000 Series, BARTS,
    AMD Radeon HD 6800 Series, AMD Radeon HD 6700 Series, TURKS, CAICOS,
    ARUBA, TAHITI, PITCAIRN, VERDE, OLAND, HAINAN, BONAIRE, KABINI,
    MULLINS, KAVERI, HAWAII
[   759.140] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[   759.140] (II) scfb: driver for wsdisplay framebuffer: scfb
[   759.140] (II) VESA: driver for VESA chipsets: vesa
[   759.140] (--) Using syscons driver with X support (version 2.0)
[   759.140] (--) using VT number 9

[   759.321] (II) [KMS] Kernel modesetting enabled.
[   759.321] (WW) Falling back to old probe method for modesetting
[   759.321] (WW) Falling back to old probe method for scfb
[   759.321] scfb trace: probe start
[   759.321] scfb trace: probe done
[   759.321] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[   759.321] (II) RADEON(0): Creating default Display subsection in Screen section
    "Default Screen Section" for depth/fbbpp 24/32
[   759.321] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32
[   759.321] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
[   759.321] (==) RADEON(0): Default visual is TrueColor
[   759.322] (==) RADEON(0): RGB weight 888
[   759.322] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
[   759.322] (--) RADEON(0): Chipset: "ATI Radeon HD 5700 Series" (ChipID = 0x68b8)
[   759.322] (II) Loading sub module "fb"
[   759.322] (II) LoadModule: "fb"
[   759.336] (II) Loading /usr/local/lib/xorg/modules/libfb.so
[   759.370] (II) Module fb: vendor="X.Org Foundation"
[   759.370]     compiled for 1.18.4, module version = 1.0.0
[   759.370]     ABI class: X.Org ANSI C Emulation, version 0.4
[   759.370] (II) Loading sub module "dri2"
[   759.370] (II) LoadModule: "dri2"
[   759.370] (II) Module "dri2" already built-in
[   761.381] (II) Loading sub module "glamoregl"
[   761.381] (II) LoadModule: "glamoregl"
[   761.382] (II) Loading /usr/local/lib/xorg/modules/libglamoregl.so
[   761.480] (II) Module glamoregl: vendor="X.Org Foundation"
[   761.480]     compiled for 1.18.4, module version = 1.0.0
[   761.480]     ABI class: X.Org ANSI C Emulation, version 0.4
[   761.480] (II) glamor: OpenGL accelerated X.org driver based.
[   761.523] (II) glamor: EGL version 1.5:
[   761.586] (II) RADEON(0): glamor detected, initialising EGL layer.
[   761.586] (II) RADEON(0): KMS Color Tiling: enabled
[   761.586] (II) RADEON(0): KMS Color Tiling 2D: enabled
[   761.586] (==) RADEON(0): TearFree property default: auto
[   761.586] (II) RADEON(0): KMS Pageflipping: enabled
[   761.604] (II) RADEON(0): Output DisplayPort-0 has no monitor section
[   761.604] (II) RADEON(0): Output HDMI-0 has no monitor section
[   761.636] (II) RADEON(0): Output DVI-0 has no monitor section
[   761.642] (II) RADEON(0): Output DVI-1 has no monitor section
[   761.660] (II) RADEON(0): EDID for output DisplayPort-0
[   761.660] (II) RADEON(0): EDID for output HDMI-0
[   761.692] (II) RADEON(0): EDID for output DVI-0
[   761.692] (II) RADEON(0): Manufacturer: DEL  Model: 4038  Serial#: 808792405
[   761.692] (II) RADEON(0): Year: 2008  Week: 25
[   761.692] (II) RADEON(0): EDID Version: 1.3
[   761.692] (II) RADEON(0): Analog Display Input,  Input Voltage Level: 0.700/0.700 V
[   761.692] (II) RADEON(0): Sync:  Separate
[   761.692] (II) RADEON(0): Max Image Size [cm]: horiz.: 47  vert.: 29
[   761.692] (II) RADEON(0): Gamma: 2.20
[   761.692] (II) RADEON(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display
[   761.692] (II) RADEON(0): First detailed timing is preferred mode
[   761.692] (II) RADEON(0): redX: 0.669 redY: 0.322   greenX: 0.220 greenY: 0.668
[   761.692] (II) RADEON(0): blueX: 0.146 blueY: 0.077   whiteX: 0.313 whiteY: 0.329
[   761.692] (II) RADEON(0): Supported established timings:
[   761.692] (II) RADEON(0): 720x400@70Hz
[   761.692] (II) RADEON(0): 640x480@60Hz
[   761.692] (II) RADEON(0): 640x480@75Hz
[   761.692] (II) RADEON(0): 800x600@60Hz
[   761.692] (II) RADEON(0): 800x600@75Hz
[   761.692] (II) RADEON(0): 1024x768@60Hz
[   761.692] (II) RADEON(0): 1024x768@75Hz
[   761.692] (II) RADEON(0): 1280x1024@75Hz
[   761.692] (II) RADEON(0): Manufacturer's mask: 0
[   761.692] (II) RADEON(0): Supported standard timings:
[   761.692] (II) RADEON(0): #0: hsize: 1152  vsize 864  refresh: 75  vid: 20337
[   761.692] (II) RADEON(0): #1: hsize: 1280  vsize 1024  refresh: 60  vid: 32897
[   761.692] (II) RADEON(0): #2: hsize: 1680  vsize 1050  refresh: 60  vid: 179
[   761.692] (II) RADEON(0): Supported detailed timing:
[   761.692] (II) RADEON(0): clock: 146.2 MHz   Image Size:  473 x 296 mm
[   761.692] (II) RADEON(0): h_active: 1680  h_sync: 1784  h_sync_end 1960 h_blank_end 2240 h_border: 0
[   761.692] (II) RADEON(0): v_active: 1050  v_sync: 1053  v_sync_end 1059 v_blanking: 1089 v_border: 0
[   761.692] (II) RADEON(0): Serial No: G494H86F051U
[   761.692] (II) RADEON(0): Monitor name: SP2208WFP
[   761.692] (II) RADEON(0): Ranges: V min: 56 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 165 MHz
[   761.692] (II) RADEON(0): EDID (in hex):
[   761.693] (II) RADEON(0):     00ffffffffffff0010ac384055313530
[   761.693] (II) RADEON(0):     19120103682f1d78ea64b5ab5238ab25
[   761.693] (II) RADEON(0):     135054a54b00714f8180b30001010101
[   761.693] (II) RADEON(0):     01010101010121399030621a274068b0
[   761.693] (II) RADEON(0):     3600d9281100001c000000ff00473439
[   761.693] (II) RADEON(0):     3448383646303531550a000000fc0053
[   761.693] (II) RADEON(0):     50323230385746500a202020000000fd
[   761.693] (II) RADEON(0):     00384c1e5310000a2020202020200080
[   761.693] (II) RADEON(0): Printing probed modes for output DVI-0
[   761.693] (II) RADEON(0): Modeline "1680x1050"x60.0  146.25  1680 1784 1960 2240  1050 1053 1059 1089 -hsync +vsync (65.3 kHz eP)
[   761.693] (II) RADEON(0): Modeline "1280x1024"x75.0  135.00  1280 1296 1440 1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
[   761.693] (II) RADEON(0): Modeline "1280x1024"x60.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
[   761.693] (II) RADEON(0): Modeline "1152x864"x75.0  108.00  1152 1216 1344 1600  864 865 868 900 +hsync +vsync (67.5 kHz e)
[   761.693] (II) RADEON(0): Modeline "1024x768"x75.0   78.75  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.0 kHz e)
[   761.693] (II) RADEON(0): Modeline "1024x768"x60.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
[   761.693] (II) RADEON(0): Modeline "800x600"x75.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz e)
[   761.693] (II) RADEON(0): Modeline "800x600"x60.3   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
[   761.693] (II) RADEON(0): Modeline "640x480"x75.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz e)
[   761.693] (II) RADEON(0): Modeline "640x480"x59.9   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)
[   761.693] (II) RADEON(0): Modeline "720x400"x70.1   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz e)
[   761.699] (II) RADEON(0): EDID for output DVI-1
[   761.699] (II) RADEON(0): Output DisplayPort-0 disconnected
[   761.699] (II) RADEON(0): Output HDMI-0 disconnected
[   761.699] (II) RADEON(0): Output DVI-0 connected
[   761.699] (II) RADEON(0): Output DVI-1 disconnected
[   761.699] (II) RADEON(0): Using exact sizes for initial modes
[   761.699] (II) RADEON(0): Output DVI-0 using initial mode 1680x1050 +0+0
[   761.699] (II) RADEON(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated.
[   761.699] (II) RADEON(0): mem size init: gart size :3fdde000 vram size: s:40000000 visible:f5bd000
[   761.699] (==) RADEON(0): DPI set to (96, 96)
[   761.699] (II) Loading sub module "ramdac"
[   761.699] (II) LoadModule: "ramdac"
[   761.699] (II) Module "ramdac" already built-in
[   761.699] (II) UnloadModule: "modesetting"
[   761.699] (II) Unloading modesetting
[   761.699] (II) UnloadModule: "scfb"
[   761.699] (II) Unloading scfb
[   761.699] (II) UnloadModule: "vesa"
[   761.699] (II) Unloading vesa
[   761.699] (--) Depth 24 pixmap format is 32 bpp
[   761.716] (II) RADEON(0): [DRI2] Setup complete
[   761.716] (II) RADEON(0): [DRI2]   DRI driver: r600
[   761.716] (II) RADEON(0): [DRI2]   VDPAU driver: r600
[   761.716] (II) RADEON(0): Front buffer size: 7087K
[   761.716] (II) RADEON(0): VRAM usage limit set to 220007K
[   761.736] (II) RADEON(0): SYNC extension fences enabled
[   761.736] (II) RADEON(0): Present extension enabled
[   761.736] (==) RADEON(0): DRI3 enabled
[   761.736] (==) RADEON(0): Backing store enabled
[   761.736] (II) RADEON(0): Direct rendering enabled
[   761.787] (II) RADEON(0): Use GLAMOR acceleration.
[   761.787] (II) RADEON(0): Acceleration enabled
[   761.787] (==) RADEON(0): DPMS enabled
[   761.787] (==) RADEON(0): Silken mouse enabled
[   761.787] (II) RADEON(0): Set up textured video (glamor)
[   761.800] (II) RADEON(0): [XvMC] Associated with GLAMOR Textured Video.
[   761.800] (II) RADEON(0): [XvMC] Extension initialized.
[   761.800] (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR disabled message.
[   761.801] (--) RandR disabled
[   761.811] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[   761.811] (II) AIGLX: enabled GLX_ARB_create_context
[   761.811] (II) AIGLX: enabled GLX_ARB_create_context_profile
[   761.811] (II) AIGLX: enabled GLX_EXT_create_context_es{,2}_profile
[   761.812] (II) AIGLX: enabled GLX_INTEL_swap_event
[   761.812] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
[   761.812] (II) AIGLX: enabled GLX_EXT_framebuffer_sRGB
[   761.812] (II) AIGLX: enabled GLX_ARB_fbconfig_float
[   761.812] (II) AIGLX: enabled GLX_EXT_fbconfig_packed_float
[   761.812] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
[   761.812] (II) AIGLX: enabled GLX_ARB_create_context_robustness
[   761.813] (II) AIGLX: Loaded and initialized r600
[   761.813] (II) GLX: Initialized DRI2 GL provider for screen 0
[   761.823] (II) RADEON(0): Setting screen physical size to 444 x 277
[   762.793] (II) config/devd: probing input devices...
[   762.793] (II) config/devd: adding input device (null) (/dev/kbdmux)
[   762.793] (II) LoadModule: "kbd"
[   762.793] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so
[   762.801] (II) Module kbd: vendor="X.Org Foundation"
[   762.801]     compiled for 1.18.4, module version = 1.9.0
[   762.802]     Module class: X.Org XInput Driver
[   762.802]     ABI class: X.Org XInput driver, version 22.1
[   762.802] (II) Using input driver 'kbd' for 'kbdmux'
[   762.802] (**) kbdmux: always reports core events
[   762.802] (**) kbdmux: always reports core events
[   762.802] (**) Option "Protocol" "standard"
[   762.802] (**) Option "XkbRules" "base"
[   762.802] (**) Option "XkbModel" "pc105"
[   762.802] (**) Option "XkbLayout" "us"
[   762.802] (**) Option "config_info" "devd:kbdmux"
[   762.802] (II) XINPUT: Adding extended input device "kbdmux" (type: KEYBOARD, id 6)
[   762.993] (II) config/devd: kbdmux is enabled, ignoring device ukbd0
[   762.993] (II) config/devd: kbdmux is enabled, ignoring device ukbd1
[   762.993] (II) config/devd: kbdmux is enabled, ignoring device atkbd0
[   762.993] (II) config/devd: adding input device (null) (/dev/sysmouse)
[   762.993] (II) LoadModule: "mouse"
[   762.994] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so
[   763.023] (II) Module mouse: vendor="X.Org Foundation"
[   763.023]     compiled for 1.18.4, module version = 1.9.3
[   763.023]     Module class: X.Org XInput Driver
[   763.023]     ABI class: X.Org XInput driver, version 22.1
[   763.023] (II) Using input driver 'mouse' for 'sysmouse'
[   763.023] (**) sysmouse: always reports core events
[   763.023] (**) Option "Device" "/dev/sysmouse"
[   763.023] (==) sysmouse: Protocol: "Auto"
[   763.023] (**) sysmouse: always reports core events
[   763.023] (==) sysmouse: Emulate3Buttons, Emulate3Timeout: 50
[   763.023] (**) sysmouse: ZAxisMapping: buttons 4 and 5
[   763.023] (**) sysmouse: Buttons: 5
[   763.023] (**) Option "config_info" "devd:sysmouse"
[   763.023] (II) XINPUT: Adding extended input device "sysmouse" (type: MOUSE, id 7)
[   763.023] (**) sysmouse: (accel) keeping acceleration scheme 1
[   763.023] (**) sysmouse: (accel) acceleration profile 0
[   763.023] (**) sysmouse: (accel) acceleration factor: 2.000
[   763.023] (**) sysmouse: (accel) acceleration threshold: 4
[   763.023] (II) sysmouse: SetupAuto: hw.iftype is 4, hw.model is 0
[   763.023] (II) sysmouse: SetupAuto: protocol is SysMouse
[   763.024] (II) config/devd: device /dev/ums0 already opened
[   763.024] (II) config/devd: device /dev/ums1 already opened
[  1246.688] (II) RADEON(0): EDID vendor "DEL", prod id 16440
[  1246.688] (II) RADEON(0): Using EDID range info for horizontal sync
[  1246.688] (II) RADEON(0): Using EDID range info for vertical refresh
[  1246.688] (II) RADEON(0): Printing DDC gathered Modelines:
[  1246.688] (II) RADEON(0): Modeline "1680x1050"x0.0  146.25  1680 1784 1960 2240  1050 1053 1059 1089 -hsync +vsync (65.3 kHz eP)
[  1246.688] (II) RADEON(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
[  1246.688] (II) RADEON(0): Modeline "640x480"x0.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz e)
[  1246.688] (II) RADEON(0): Modeline "640x480"x0.0   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)
[  1246.688] (II) RADEON(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz e)
[  1246.689] (II) RADEON(0): Modeline "1280x1024"x0.0  135.00  1280 1296 1440 1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
[  1246.689] (II) RADEON(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.0 kHz e)
[  1246.689] (II) RADEON(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
[  1246.689] (II) RADEON(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz e)
[  1246.689] (II) RADEON(0): Modeline "1152x864"x0.0  108.00  1152 1216 1344 1600  864 865 868 900 +hsync +vsync (67.5 kHz e)
[  1246.689] (II) RADEON(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
[  1246.744] (II) RADEON(0): EDID vendor "DEL", prod id 16440
[  1246.744] (II) RADEON(0): Using hsync ranges from config file
[  1246.744] (II) RADEON(0): Using vrefresh ranges from config file
[  1246.744] (II) RADEON(0): Printing DDC gathered Modelines:
[  1246.744] (II) RADEON(0): Modeline "1680x1050"x0.0  146.25  1680 1784 1960 2240  1050 1053 1059 1089 -hsync +vsync (65.3 kHz eP)
[  1246.744] (II) RADEON(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
[  1246.744] (II) RADEON(0): Modeline "640x480"x0.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz e)
[  1246.744] (II) RADEON(0): Modeline "640x480"x0.0   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)
[  1246.744] (II) RADEON(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz e)
[  1246.744] (II) RADEON(0): Modeline "1280x1024"x0.0  135.00  1280 1296 1440 1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
[  1246.744] (II) RADEON(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.0 kHz e)
[  1246.744] (II) RADEON(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
[  1246.744] (II) RADEON(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz e)
[  1246.745] (II) RADEON(0): Modeline "1152x864"x0.0  108.00  1152 1216 1344 1600  864 865 868 900 +hsync +vsync (67.5 kHz e)
[  1246.745] (II) RADEON(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
[  1712.388] (II) config/devd: ignoring device hdac0
[  1712.406] (II) config/devd: ignoring device hdac1
[  1712.441] (II) config/devd: ignoring device pcm0
[  1712.444] (II) config/devd: ignoring device pcm1
[  1712.448] (II) config/devd: ignoring device pcm2
[  1712.458] (II) config/devd: ignoring device pcm3
[  1712.460] (II) config/devd: ignoring device hdaa0
[  1712.460] (II) config/devd: ignoring device hdacc0
[  1712.471] (II) config/devd: ignoring device pcm4
[  1712.477] (II) config/devd: ignoring device hdaa1
[  1712.478] (II) config/devd: ignoring device hdacc1

dmesg output:

Copyright (c) 1992-2020 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.3-STABLE #23 r359068: Wed Mar 18 14:31:28 CDT 2020
    bennett@hellas:/usr/obj/usr/src/sys/hellas amd64
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM 8.0.1)
VT(vga): resolution 640x480
CPU microcode: updated from 0x60b to 0x60f
CPU: Intel(R) Core(TM)2 Extreme CPU X9650  @ 3.00GHz (3333.40-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x10676  Family=0x6  Model=0x17  Stepping=6
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x8e3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1>
  AMD Features=0x20100800<SYSCALL,NX,LM>
  AMD Features2=0x1<LAHF>
  VT-x: HLT,PAUSE
  TSC: P-state invariant, performance statistics
real memory  = 8589934592 (8192 MB)
avail memory = 8260100096 (7877 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table: <DELL   MC09   >
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s)
WARNING: VIMAGE (virtualized network stack) is a highly experimental feature.
ioapic0: Changing APIC ID to 4
ioapic0 <Version 1.1> irqs 0-23 on motherboard
SMP: AP CPU #3 Launched!
SMP: AP CPU #2 Launched!
SMP: AP CPU #1 Launched!
Timecounter "TSC-low" frequency 1666698635 Hz quality 1000
random: entropy device external interface
kbd1 at kbdmux0
module_register_init: MOD_LOAD (vesa, 0xffffffff80fb35e0, 0) error 19
nexus0
vtvga0: <VT VGA driver> on motherboard
cryptosoft0: <software crypto> on motherboard
aesni0: No AESNI support.
acpi0: <DELL MC09   > on motherboard
acpi0: Power Button (fixed)
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0
cpu2: <ACPI CPU> on acpi0
cpu3: <ACPI CPU> on acpi0
attimer0: <AT timer> port 0x40-0x43 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
hpet0: <High Precision Event Timer> iomem 0xfeff0000-0xfeff03ff irq 0,8 on acpi0
device_attach: hpet0 attach returned 12
atrtc0: <AT realtime clock> port 0x70-0x71,0x72-0x73 on acpi0
atrtc0: registered as a time-of-day clock, resolution 1.000000s
Event timer "RTC" frequency 32768 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
acpi_button0: <Power Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pci0: <memory, RAM> at device 0.1 (no driver attached)
pci0: <memory, RAM> at device 0.2 (no driver attached)
pci0: <memory, RAM> at device 0.3 (no driver attached)
pci0: <memory, RAM> at device 0.4 (no driver attached)
pci0: <memory, RAM> at device 0.5 (no driver attached)
pci0: <memory, RAM> at device 0.6 (no driver attached)
pci0: <memory, RAM> at device 0.7 (no driver attached)
pci0: <memory, RAM> at device 1.0 (no driver attached)
pci0: <memory, RAM> at device 1.1 (no driver attached)
pci0: <memory, RAM> at device 1.2 (no driver attached)
pci0: <memory, RAM> at device 1.3 (no driver attached)
pci0: <memory, RAM> at device 1.4 (no driver attached)
pci0: <memory, RAM> at device 1.5 (no driver attached)
pci0: <memory, RAM> at device 1.6 (no driver attached)
pci0: <memory, RAM> at device 1.7 (no driver attached)
pcib1: <ACPI PCI-PCI bridge> irq 16 at device 2.0 on pci0
pci1: <ACPI PCI bus> on pcib1
pcib2: <ACPI PCI-PCI bridge> irq 16 at device 4.0 on pci0
pci2: <ACPI PCI bus> on pcib2
vgapci0: <VGA-compatible display> port 0x9c00-0x9cff mem 0xc0000000-0xcfffffff,0xdfdc0000-0xdfddffff irq 16 at device 0.0 on pci2
vgapci0: Boot video device
pci2: <multimedia, HDA> at device 0.1 (no driver attached)
pci0: <memory, RAM> at device 9.0 (no driver attached)
isab0: <PCI-ISA bridge> port 0xfc00-0xfc7f at device 10.0 on pci0
isa0: <ISA bus> on isab0
ohci0: <nVidia nForce MCP55 USB Controller> mem 0xdffff000-0xdfffffff irq 22 at device 11.0 on pci0
usbus0 on ohci0
usbus0: 12Mbps Full Speed USB v1.0
ehci0: <NVIDIA nForce MCP55 USB 2.0 controller> mem 0xdfffe000-0xdfffe0ff irq 23 at device 11.1 on pci0
usbus1: EHCI version 1.0
usbus1 on ehci0
usbus1: 480Mbps High Speed USB v2.0
atapci0: <nVidia nForce MCP55 UDMA133 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xec00-0xec0f at device 13.0 on pci0
ata0: <ATA channel> at channel 0 on atapci0
ata1: <ATA channel> at channel 1 on atapci0
atapci1: <nVidia nForce MCP55 SATA300 controller> port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xd800-0xd80f mem 0xdfffd000-0xdfffdfff irq 20 at device 14.0 on pci0
ata2: <ATA channel> at channel 0 on atapci1
ata3: <ATA channel> at channel 1 on atapci1
atapci2: <nVidia nForce MCP55 SATA300 controller> port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xc400-0xc40f mem 0xdfffc000-0xdfffcfff irq 21 at device 14.1 on pci0
ata4: <ATA channel> at channel 0 on atapci2
ata5: <ATA channel> at channel 1 on atapci2
atapci3: <nVidia nForce MCP55 SATA300 controller> port 0xc000-0xc007,0xbc00-0xbc03,0xb800-0xb807,0xb400-0xb403,0xb000-0xb00f mem 0xdfffb000-0xdfffbfff irq 20 at device 14.2 on pci0
ata6: <ATA channel> at channel 0 on atapci3
ata7: <ATA channel> at channel 1 on atapci3
pcib3: <ACPI PCI-PCI bridge> at device 15.0 on pci0
pci3: <ACPI PCI bus> on pcib3
fwohci0: <Texas Instruments TSB43AB22/A> mem 0xdfeff000-0xdfeff7ff,0xdfef8000-0xdfefbfff irq 19 at device 7.0 on pci3
fwohci0: OHCI version 1.10 (ROM=0)
fwohci0: No. of Isochronous channels is 4.
fwohci0: EUI64 52:f6:94:66:00:1d:09:8a
fwohci0: Phy 1394a available S400, 2 ports.
fwohci0: Link S400, max_rec 2048 bytes.
firewire0: <IEEE1394(FireWire) bus> on fwohci0
dcons_crom0: <dcons configuration ROM> on firewire0
dcons_crom0: bus_addr 0x5a000
fwe0: <Ethernet over FireWire> on firewire0
if_fwe0: Fake Ethernet address: 52:f6:94:1d:09:8a
fwe0: Ethernet address: 52:f6:94:1d:09:8a
fwip0: <IP over FireWire> on firewire0
fwip0: Firewire address: 52:f6:94:66:00:1d:09:8a @ 0xfffe00000000, S400, maxrec 2048
sbp0: <SBP-2/SCSI over FireWire> on firewire0
fwohci0: Initiate bus reset
fwohci0: fwohci_intr_core: BUS reset
fwohci0: PhysicalUpperBound register is not implemented.  Physical memory access is limited to the first 4GB
fwohci0: PhysicalUpperBound = 0x00000000
fwohci0: fwohci_intr_core: node_id=0x00000001, SelfID Count=1, CYCLEMASTER mode
firewire0: 2 nodes, maxhop <= 1 cable IRM irm(1)  (me)
firewire0: bus manager 1
pci0: <multimedia, HDA> at device 15.1 (no driver attached)
nfe0: <NVIDIA nForce MCP55 Networking Adapter> port 0xac00-0xac07 mem 0xdfffa000-0xdfffafff,0xdfff9000-0xdfff90ff,0xdfff8000-0xdfff800f irq 23 at device 17.0 on pci0
miibus0: <MII bus> on nfe0
ukphy0: <Generic IEEE 802.3u media interface> PHY 0 on miibus0
ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
nfe0: Using defaults for TSO: 65518/35/2048
nfe0: Ethernet address: 00:22:19:0f:48:3d
nfe1: <NVIDIA nForce MCP55 Networking Adapter> port 0xa800-0xa807 mem 0xdfff7000-0xdfff7fff,0xdfff6000-0xdfff60ff,0xdfff5000-0xdfff500f irq 22 at device 18.0 on pci0
miibus1: <MII bus> on nfe1
ukphy1: <Generic IEEE 802.3u media interface> PHY 1 on miibus1
ukphy1:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
nfe1: Using defaults for TSO: 65518/35/2048
nfe1: Ethernet address: 00:22:19:0f:48:3e
pcib4: <ACPI PCI-PCI bridge> at device 21.0 on pci0
pci4: <ACPI PCI bus> on pcib4
atapci4: <JMicron JMB363 UDMA133 controller> port 0x8c00-0x8c07,0x8800-0x8803,0x8400-0x8407,0x8000-0x8003,0x7c00-0x7c0f mem 0xdfcfe000-0xdfcfffff irq 16 at device 0.0 on pci4
ahci0: <JMicron JMB363 AHCI SATA controller> at channel -1 on atapci4
ahci0: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported
ahci0: quirks=0x1<NOFORCE>
ahcich0: <AHCI channel> at channel 0 on ahci0
ahcich1: <AHCI channel> at channel 1 on ahci0
ata8: <ATA channel> at channel 0 on atapci4
pcib5: <ACPI PCI-PCI bridge> at device 22.0 on pci0
pci5: <ACPI PCI bus> on pcib5
xhci0: <XHCI (generic) USB 3.0 controller> mem 0xdfbfe000-0xdfbfffff irq 16 at device 0.0 on pci5
xhci0: 64 bytes context size, 32-bit DMA
xhci0: Unable to map MSI-X table
usbus2 on xhci0
usbus2: 5.0Gbps Super Speed USB v3.0
pcib6: <ACPI PCI-PCI bridge> at device 23.0 on pci0
pci6: <ACPI PCI bus> on pcib6
xhci1: <NEC uPD720200 USB 3.0 controller> mem 0xdfafe000-0xdfafffff irq 16 at device 0.0 on pci6
xhci1: 32 bytes context size, 32-bit DMA
xhci1: Unable to map MSI-X table
usbus3 on xhci1
usbus3: 5.0Gbps Super Speed USB v3.0
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
orm0: <ISA Option ROMs> at iomem 0xd0000-0xd3fff,0xd4000-0xd6fff on isa0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
ppc0: cannot reserve I/O port range
coretemp0: <CPU On-Die Thermal Sensors> on cpu0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
coretemp1: <CPU On-Die Thermal Sensors> on cpu1
est1: <Enhanced SpeedStep Frequency Control> on cpu1
coretemp2: <CPU On-Die Thermal Sensors> on cpu2
est2: <Enhanced SpeedStep Frequency Control> on cpu2
coretemp3: <CPU On-Die Thermal Sensors> on cpu3
est3: <Enhanced SpeedStep Frequency Control> on cpu3
ZFS filesystem version: 5
ZFS storage pool version: features support (5000)
Timecounters tick every 1.000 msec
DUMMYNET 0xfffff80003723380 with IPv6 initialized (100409)
load_dn_sched dn_sched FQ_CODEL loaded
load_dn_sched dn_sched FQ_PIE loaded
load_dn_sched dn_sched PRIO loaded
load_dn_sched dn_sched QFQ loaded
load_dn_sched dn_sched RR loaded
load_dn_sched dn_sched WF2Q+ loaded
load_dn_sched dn_sched FIFO loaded
load_dn_aqm dn_aqm CODEL loaded
load_dn_aqm dn_aqm PIE loaded
ugen1.1: <nVidia EHCI root HUB> at usbus1
ugen0.1: <nVidia OHCI root HUB> at usbus0
ugen2.1: <0x1912 XHCI root HUB> at usbus2
ugen3.1: <0x1033 XHCI root HUB> at usbus3
uhub0: <nVidia EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
uhub1: <0x1033 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus3
uhub2: <nVidia OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
uhub3: <0x1912 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2
firewire0: fw_explore_node: fwdev->speed(S800) decremented due to negotiation
sbp0: sbp_show_sdev_info: sbp0:0:0: ordered:1 type:0 EUI:0090a99f91a48dde node:0 speed:2 maxrec:8
sbp0: sbp_show_sdev_info: sbp0:0:0 'WD' 'My Book' '001028'
sbp0: sbp_show_sdev_info: sbp0:0:1: ordered:1 type:13 EUI:0090a99f91a48dde node:0 speed:2 maxrec:8
sbp0: sbp_show_sdev_info: sbp0:0:1 'WD' 'My Book' '001028'
uhub1: 4 ports with 4 removable, self powered
uhub2: 10 ports with 10 removable, self powered
uhub3: 8 ports with 8 removable, self powered
ugen3.2: <VIA Labs, Inc. USB3.0 Hub> at usbus3
uhub4 on uhub1
uhub4: <VIA Labs, Inc. USB3.0 Hub, class 9/0, rev 3.00/90.91, addr 1> on usbus3
uhub4: 4 ports with 4 removable, self powered
ugen2.2: <Seagate Backup+ Desk> at usbus2
umass0 on uhub3
umass0: <Seagate Backup+ Desk, class 0/0, rev 3.00/1.00, addr 1> on usbus2
umass0:  SCSI over Bulk-Only; quirks = 0x0100
umass0:12:0: Attached to scbus12
ugen3.3: <VIA Labs, Inc. USB3.0 Hub> at usbus3
uhub5 on uhub4
uhub5: <VIA Labs, Inc. USB3.0 Hub, class 9/0, rev 3.00/90.91, addr 2> on usbus3
uhub5: 4 ports with 4 removable, self powered
uhub0: 10 ports with 10 removable, self powered
ugen3.4: <VIA Labs, Inc. USB2.0 Hub> at usbus3
uhub6 on uhub1
uhub6: <VIA Labs, Inc. USB2.0 Hub, class 9/0, rev 2.10/90.90, addr 3> on usbus3
uhub6: 4 ports with 4 removable, self powered
ugen1.2: <vendor 0x05e3 USB2.0 Hub> at usbus1
uhub7 on uhub0
uhub7: <vendor 0x05e3 USB2.0 Hub, class 9/0, rev 2.00/32.98, addr 2> on usbus1
ugen3.5: <VIA Labs, Inc. USB2.0 Hub> at usbus3
uhub8 on uhub6
uhub8: <VIA Labs, Inc. USB2.0 Hub, class 9/0, rev 2.10/90.90, addr 4> on usbus3
uhub7: 4 ports with 4 removable, self powered
uhub8: 4 ports with 4 removable, self powered
ugen1.3: <Logitech USB Trackball> at usbus1
(probe7:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe7:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(probe7:umass-sim0:0:0:0): Retrying command
ugen1.4: <vendor 0x05e3 USB2.0 Hub> at usbus1
uhub9 on uhub0
uhub9: <vendor 0x05e3 USB2.0 Hub, class 9/0, rev 2.00/32.98, addr 4> on usbus1
ugen2.3: <Seagate FreeAgent GoFlex> at usbus2
umass1 on uhub3
umass1: <Seagate FreeAgent GoFlex, class 0/0, rev 3.00/1.00, addr 2> on usbus2
umass1:  SCSI over Bulk-Only; quirks = 0xc101
umass1:13:1: Attached to scbus13
uhub9: 4 ports with 4 removable, self powered
ugen0.2: <Dell Dell USB Keyboard Hub> at usbus0
uhub10 on uhub2
uhub10: <Dell USB Keyboard Hub> on usbus0
ugen1.5: <vendor 0x04b4 product 0x6560> at usbus1
uhub11 on uhub0
uhub11: <vendor 0x04b4 product 0x6560, class 9/0, rev 2.00/90.15, addr 5> on usbus1
ugen2.4: <vendor 0x1f75 product 0x0621> at usbus2
umass2 on uhub3
umass2: <vendor 0x1f75 product 0x0621, class 0/0, rev 3.00/0.36, addr 3> on usbus2
umass2:  SCSI over Bulk-Only; quirks = 0x0100
umass2:14:2: Attached to scbus14
uhub10: 3 ports with 2 removable, bus powered
uhub11: 4 ports with 4 removable, self powered
ugen0.3: <Dell Dell USB Keyboard> at usbus0
ukbd0 on uhub10
ukbd0: <Dell USB Keyboard> on usbus0
kbd2 at ukbd0
random: unblocking device.
ugen1.6: <DELL CAB-200> at usbus1
umass3 on uhub11
umass3: <DELL CAB-200, class 0/0, rev 2.00/7.08, addr 6> on usbus1
umass3:  SCSI over Bulk-Only; quirks = 0xc000
umass3:15:3: Attached to scbus15
(probe7:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe7:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(probe7:umass-sim0:0:0:0): Retrying command
ugen1.7: <Logitech BT Mini-Receiver> at usbus1
uhub12 on uhub11
uhub12: <Logitech BT Mini-Receiver, class 9/0, rev 2.00/58.00, addr 7> on usbus1
(probe7:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe7:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(probe7:umass-sim0:0:0:0): Retrying command
uhub12: 3 ports with 0 removable, bus powered
ugen1.8: <Logitech BT Mini-Receiver> at usbus1
ugen1.9: <Logitech BT Mini-Receiver> at usbus1
ukbd1 on uhub12
ukbd1: <Logitech BT Mini-Receiver, class 0/0, rev 2.00/58.00, addr 9> on usbus1
kbd3 at ukbd1
(probe0:umass-sim2:2:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:umass-sim2:2:0:0): CAM status: CCB request completed with an error
(probe0:umass-sim2:2:0:0): Retrying command
ugen1.10: <Logitech BT Mini-Receiver> at usbus1
(probe0:umass-sim2:2:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:umass-sim2:2:0:0): CAM status: CCB request completed with an error
(probe0:umass-sim2:2:0:0): Retrying command
usbd_setup_device_desc: getting device descriptor at addr 4 failed, USB_ERR_STALLED
usbd_setup_device_desc: getting device descriptor at addr 4 failed, USB_ERR_STALLED
usbd_setup_device_desc: getting device descriptor at addr 4 failed, USB_ERR_STALLED
usbd_setup_device_desc: getting device descriptor at addr 4 failed, USB_ERR_STALLED
usbd_setup_device_desc: getting device descriptor at addr 4 failed, USB_ERR_STALLED
ugen0.4: <Unknown > at usbus0 (disconnected)
uhub_reattach_port: could not allocate new device
(probe0:umass-sim2:2:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:umass-sim2:2:0:0): CAM status: CCB request completed with an error
(probe0:umass-sim2:2:0:0): Retrying command
(probe0:umass-sim2:2:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:umass-sim2:2:0:0): CAM status: CCB request completed with an error
(probe0:umass-sim2:2:0:0): Retrying command
ada0 at ata4 bus 0 scbus4 target 0 lun 0
ada0: <ST1000DM003-9YN162 CC4H> ATA8-ACS SATA 3.x device
ada0: Serial Number Z1D4Y5W1
ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada0: 953869MB (1953525168 512 byte sectors)
ada0: quirks=0x1<4K>
ada1 at ata5 bus 0 scbus5 target 0 lun 0
ada1: <WDC WD1003FZEX-00MK2A0 01.01A01> ACS-2 ATA SATA 3.x device
ada1: Serial Number WD-WCC3F1AY9KR3
ada1: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada1: 953869MB (1953525168 512 byte sectors)
ada1: quirks=0x1<4K>
ada2 at ata6 bus 0 scbus6 target 0 lun 0
ada2: <ST2000DM001-1CH164 CC27> ACS-2 ATA SATA 3.x device
ada2: Serial Number Z1E4Q0T1
ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada2: 1907729MB (3907029168 512 byte sectors)
ada2: quirks=0x1<4K>
ada3 at ata7 bus 0 scbus7 target 0 lun 0
ada3: <WDC WD2003FZEX-00SRLA0 01.01A01> ACS-3 ATA SATA 3.x device
ada3: Serial Number WD-WCC6N7KD2YAK
ada3: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada3: 1907729MB (3907029168 512 byte sectors)
ada3: quirks=0x1<4K>
ada4 at ahcich0 bus 0 scbus9 target 0 lun 0
ada4: <WDC WD3000FYYZ-01UL1B3 01.01K04> ATA8-ACS SATA 3.x device
ada4: Serial Number WD-WMC130F2V1RN
ada4: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes)
ada4: Command Queueing enabled
ada4: 2861588MB (5860533168 512 byte sectors)
ses0 at sbp0 bus 0 scbus8 target 0 lun 1
cd0 at ata2 bus 0 scbus2 target 0 lun 0
ses0: cd0: <WD My Book Device > Fixed Enclosure Services SPC-2 SCSI device
<HL-DT-ST DVD+-RW GSA-H73N C106> Removable CD-ROM SCSI device
ses0: 50.000MB/s transferscd0: 150.000MB/s transfers
ses0: SES Device
 (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes)
cd0: Attempt to query device size failed: NOT READY, Medium not present
cd1 at ata3 bus 0 scbus3 target 0 lun 0
cd1: <PLDS BD-RE DH-4B1S 7D14> Removable CD-ROM SCSI device
cd1: Serial Number 0000090825
cd1: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes)
cd1: Attempt to query device size failed: NOT READY, Medium not present
da2 at umass-sim1 bus 1 scbus13 target 0 lun 0
da2: <Seagate FreeAgent GoFlex 210> Fixed Direct Access SCSI device
da2: Serial Number NA0E8J03
da2: 400.000MB/s transfers
da2: 476940MB (976773167 512 byte sectors)
da2: quirks=0x2<NO_6_BYTE>
da3 at umass-sim2 bus 2 scbus14 target 0 lun 0
da3: <WDC WD30 00FYYZ-01UL1B3 > Fixed Direct Access SPC-4 SCSI device
da3: Serial Number 1
da3: 400.000MB/s transfers
da3: 2861588MB (5860533168 512 byte sectors)
da3: quirks=0x2<NO_6_BYTE>
da1 at umass-sim0 bus 0 scbus12 target 0 lun 0
da1: <  > Fixed Direct Access SCSI device
da1: Serial Number NA5KYLVM
da1: 400.000MB/s transfers
da1: 1907729MB (3907029167 512 byte sectors)
da1: quirks=0x2<NO_6_BYTE>
da0 at sbp0 bus 0 scbus8 target 0 lun 0
da0: <WD My Book 1028> Fixed Direct Access SPC-2 SCSI device
da0: 50.000MB/s transfers
da0: 1907729MB (3907029168 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>
GEOM_ELI: Device ada0p2.eli created.
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI:     Crypto: software
da4 at umass-sim3 bus 3 scbus15 target 0 lun 0
da4: <DELL USB   HS-CF Card 7.08> Removable Direct Access SCSI device
da4: Serial Number 000001034CE8
da4: 40.000MB/s transfers
da4: Attempt to query device size failed: NOT READY, Medium not present
da4: quirks=0x2<NO_6_BYTE>
hwpmc: SOFT/16/64/0x67<INT,USR,SYS,REA,WRI> TSC/1/64/0x20<REA> IAP/2/40/0x3ff<INT,USR,SYS,EDG,THR,REA,WRI,INV,QUA,PRC> IAF/3/40/0x67<INT,USR,SYS,REA,WRI>
Trying to mount root from zfs:system/ROOT/hellas.r359068 []...
da5 at umass-sim3 bus 3 scbus15 target 0 lun 1
da5: <DELL USB   HS-xD/SM 7.08> Removable Direct Access SCSI device
da5: Serial Number 000001034CE8
da5: 40.000MB/s transfers
da5: Attempt to query device size failed: NOT READY, Medium not present
da5: quirks=0x2<NO_6_BYTE>
da6 at umass-sim3 bus 3 scbus15 target 0 lun 2
da6: <DELL USB   HS-MS Card 7.08> Removable Direct Access SCSI device
da6: Serial Number 000001034CE8
da6: 40.000MB/s transfers
da6: Attempt to query device size failed: NOT READY, Medium not present
da6: quirks=0x2<NO_6_BYTE>
da7 at umass-sim3 bus 3 scbus15 target 0 lun 3
da7: <DELL USB   HS-SD Card 7.08> Removable Direct Access SCSI device
da7: Serial Number 000001034CE8
da7: 40.000MB/s transfers
da7: Attempt to query device size failed: NOT READY, Medium not present
da7: quirks=0x2<NO_6_BYTE>
Enter passphrase for ada0p6: GEOM_ELI: Device ada0p6.eli created.
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI:     Crypto: software
GEOM_ELI: Device ada1p2.eli created.
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI:     Crypto: software
GEOM_MIRROR: Force device dbtor start due to timeout.
GEOM_ELI: Device ada1p6.eli created.
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI:     Crypto: software
GEOM_MIRROR: Device mirror/dbtor launched (1/2).
GEOM_ELI: Device ada1p13.eli created.
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI:     Crypto: software
Enter passphrase for ada4p1: GEOM_MIRROR: Force device bw1 start due to timeout.
GEOM_MIRROR: Force device bw0 start due to timeout.
GEOM_ELI: Wrong key for ada4p1. Tries left: 2.
Enter passphrase for ada4p1: GEOM_ELI: Wrong key for ada4p1. Tries left: 1.
Enter passphrase for ada4p1: GEOM_ELI: Wrong key for ada4p1. No tries left.
GEOM_MIRROR: Device mirror/bw1 launched (1/2).GEOM_MIRROR
: Device mirror/bw0 launched (1/2).
GEOM_MIRROR: Cancelling unmapped because of da0p5.
GEOM_MIRROR: Cancelling unmapped because of da1p5.
GEOM_MIRROR: Device mirror/bw2 launched (2/2).
Enter passphrase for da3p1: GEOM_ELI: Wrong key for da3p1. Tries left: 2.
Enter passphrase for da3p1: GEOM_ELI: Wrong key for da3p1. Tries left: 1.
Enter passphrase for da3p1: GEOM_ELI: Wrong key for da3p1. No tries left.
Enter passphrase for gpt/WD-WMC130F2V1RN: GEOM_ELI: Wrong key for gpt/WD-WMC130F2V1RN. Tries left: 2.
Enter passphrase for gpt/WD-WMC130F2V1RN: GEOM_ELI: Wrong key for gpt/WD-WMC130F2V1RN. Tries left: 1.
Enter passphrase for gpt/WD-WMC130F2V1RN: GEOM_ELI: Wrong key for gpt/WD-WMC130F2V1RN. No tries left.
GEOM_CONCAT: Device buildwork created (id=3312381894).
GEOM_CONCAT: Disk mirror/bw1 attached to buildwork.
GEOM_CONCAT: Disk mirror/bw0 attached to buildwork.
GEOM_CONCAT: Disk mirror/bw2 attached to buildwork.
GEOM_CONCAT: Device concat/buildwork activated.
Enter passphrase for gpt/Insignia%20case-WD%20SN%201: GEOM_ELI: Wrong key for gpt/Insignia%20case-WD%20SN%201. Tries left: 2.
Enter passphrase for gpt/Insignia%20case-WD%20SN%201: GEOM_ELI: Wrong key for gpt/Insignia%20case-WD%20SN%201. Tries left: 1.
Enter passphrase for gpt/Insignia%20case-WD%20SN%201: GEOM_ELI: Wrong key for gpt/Insignia%20case-WD%20SN%201. No tries left.
GEOM_ELI: Device mirror/dbtor.eli created.
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI:     Crypto: software
GEOM_ELI: Device ada0p4.eli created.
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI:     Crypto: software
GEOM_ELI: Device ada1p4.eli created.
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI:     Crypto: software
anon_inodefs_init:
can't re-use a leaf (debug)!
[drm] radeon kernel modesetting enabled.
drmn0: <drmn> on vgapci0
vgapci0: child drmn0 requested pci_enable_io
vgapci0: child drmn0 requested pci_enable_io
[drm] initializing kernel modesetting (JUNIPER 0x1002:0x68B8 0x1002:0x2543 0x00).
[drm] register mmio base: 0xDFDC0000
[drm] register mmio size: 131072
[drm:radeon_device_init] Unable to find PCI I/O BAR
[drm:radeon_atombios_init] Unable to find PCI I/O BAR; using MMIO for ATOM IIO
ATOM BIOS: JUNIPER
drmn0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used)
drmn0: GTT: 1024M 0x0000000040000000 - 0x000000007FFFFFFF
Failed to add WC MTRR for [0xc0000000-0xcfffffff]: -22; performance may suffer
[drm] Detected VRAM RAM=1024M, BAR=256M
[drm] RAM width 128bits DDR
[TTM] Zone  kernel: Available graphics memory: 4173008 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[drm] radeon: 1024M of VRAM memory ready
[drm] radeon: 1024M of GTT memory ready.
[drm] Loading JUNIPER Microcode
radeon/JUNIPER_pfp.bin: could not load firmware image, error 2
radeon/JUNIPER_pfp.bin: could not load firmware image, error 2
radeon/JUNIPER_me.bin: could not load firmware image, error 2
radeon/JUNIPER_me.bin: could not load firmware image, error 2
radeon/JUNIPER_rlc.bin: could not load firmware image, error 2
radeon/JUNIPER_rlc.bin: could not load firmware image, error 2
radeon/JUNIPER_smc.bin: could not load firmware image, error 2
radeon/JUNIPER_smc.bin: could not load firmware image, error 2
[drm] Internal thermal controller with fan control
[drm] radeon: dpm initialized
radeon/CYPRESS_uvd.bin: could not load firmware image, error 2
radeon/CYPRESS_uvd.bin: could not load firmware image, error 2
[drm] GART: num cpu pages 262144, num gpu pages 262144
[drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
[drm] PCIE GART of 1024M enabled (table at 0x000000000014C000).
drmn0: WB enabled
drmn0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0x0xfffff800447c6c00
drmn0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0x0xfffff800447c6c0c
drmn0: fence driver on ring 5 use gpu addr 0x000000000005c418 and cpu addr 0x0xfffff800c005c418
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
drmn0: radeon: MSI limited to 32-bit
[drm] radeon: irq initialized.
[drm] ring test on 0 succeeded in 1 usecs
[drm] ring test on 3 succeeded in 2 usecs
[drm] ring test on 5 succeeded in 1 usecs
[drm] UVD initialized successfully.
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 0 usecs
[drm] ib test on ring 5 succeeded
[drm] hw_i2c forced on, you may experience display detection problems!
[drm] Connector DP-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.DP-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector HDMI-A-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.HDMI-A-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector DVI-I-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.DVI-I-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector DVI-I-2: get mode from tunables:
[drm]   - kern.vt.fb.modes.DVI-I-2
[drm]   - kern.vt.fb.default_mode
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   DP-1
[drm]   HPD4
[drm]   DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c
[drm]   Encoders:
[drm]     DFP1: INTERNAL_UNIPHY2
[drm] Connector 1:
[drm]   HDMI-A-1
[drm]   HPD5
[drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c
[drm]   Encoders:
[drm]     DFP2: INTERNAL_UNIPHY2
[drm] Connector 2:
[drm]   DVI-I-1
[drm]   HPD1
[drm]   DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c
[drm]   Encoders:
[drm]     DFP3: INTERNAL_UNIPHY1
[drm]     CRT2: INTERNAL_KLDSCP_DAC2
[drm] Connector 3:
[drm]   DVI-I-2
[drm]   HPD6
[drm]   DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c
[drm]   Encoders:
[drm]     DFP4: INTERNAL_UNIPHY
[drm]     CRT1: INTERNAL_KLDSCP_DAC1
[drm] fb mappable at 0xC034D000
[drm] vram apper at 0xC0000000
[drm] size 7299072
[drm] fb depth is 24
[drm]    pitch is 6912
VT: Replacing driver "vga" with new "fb".
start FB_INFO:
type=11 height=1050 width=1680 depth=32
cmsize=16 size=7299072
pbase=0xc034d000 vbase=0xfffff800c034d000
name=drmn0 flags=0x0 stride=6912 bpp=32
cmap[0]=0 cmap[1]=7f0000 cmap[2]=7f00 cmap[3]=c4a000
end FB_INFO
drmn0: fb0: radeondrmfb frame buffer device
[drm] Initialized radeon 2.49.0 20080528 for drmn0 on minor 0
lo0: link state changed to UP
nfe0: link state changed to DOWN
nfe1: link state changed to DOWN
uhid0 on uhub10
uhid0: <Dell USB Keyboard> on usbus0
ums0 on uhub12
ums0: <Logitech BT Mini-Receiver, class 0/0, rev 2.00/58.00, addr 10> on usbus1
ums0: 14 buttons and [XYZT] coordinates ID=2
ums1 on uhub7
ums1: <Logitech USB Trackball, class 0/0, rev 1.10/14.00, addr 3> on usbus1
ums1: 5 buttons and [XY] coordinates ID=0
ubt0 on uhub12
ubt0: <Logitech BT Mini-Receiver, class 224/1, rev 2.00/58.00, addr 8> on usbus1
WARNING: attempt to domain_add(bluetooth) after domainfinalize()
WARNING: attempt to domain_add(netgraph) after domainfinalize()
pflog0: promiscuous mode enabled
nfe0: link state changed to UP
Accounting enabled
Comment 1 Niclas Zeising freebsd_committer freebsd_triage 2020-07-14 13:45:54 UTC
Is this a problem even after the recent updates to the graphics stack?
Have you tried 12.1 with drm-fbsd12.0-kmod or current with drm-devel-kmod?
Comment 2 Pau Amma 2020-07-14 16:34:54 UTC
(In reply to Niclas Zeising from comment #1)

*digs through old emails forwarded from linimon again*

Scott Bennett wrote, on the topic of upgrading from 11.3 to 12.1:

> > > > > > On 2020-04-13 14:06, Scott Bennett wrote:
> > > > > >
> > > > > > > If I can ever get 12.1 to build on 11.3, I can upgrade.

(The impossibility to upgrade using source being a different problem, for which they can't open a bug for yet, due to the lack of a GUI browser until X works at all.)

Does that answer your question?
Comment 3 Scott Bennett 2020-07-15 04:23:13 UTC
     I have two events to report since Pau Amma filed this PR for me.  The
first is that I can, after all, file PRs (and, I hope, comments) using lynx(1).
The other is that last month I decided to try to build 12.1-STABLE again, so I
updated my source tree, entered "make -j3 buildworld", and for the first time
ever, it didn't stop during the first few second, but instead ran to completion.
I have no idea what changed in the source tree to make that happen.  I then
built three kernels successfully, but have yet to install any of this because,
while I was waiting for an appropriate time to do it, Don Wilde began to
complain on -stable@ of symptoms in 12.1 that matched several of those for the
memory management bugs introduced into the kernel in 11.2 and still present in
11.4-PRELEASE.  That told me that at least some of those bugs had, contrary to
my hopes, made it into 12, so there was little point in going through the major
upheaval and lost time of a major release upgrade at this time.
     But to return to Niclas's query's intent, I would ask in reply, which bug
are you inquiring about?  The bug in radeonkms.ko as provided in
graphics/gpu-firmware-kmod?  Or the one in graphics/drm-fbsd11.2-kmod?
Comment 4 Niclas Zeising freebsd_committer freebsd_triage 2020-07-16 07:00:24 UTC
(In reply to Scott Bennett from comment #3)
radeonkms.ko is provided by drm-*-kmod.  gpu-firmware-kmod provides firmware that all (modern) GPUs need in order to run.
Comment 5 Scott Bennett 2020-07-16 11:10:39 UTC
Niclas, you are correct, of course.  I misstated the question.  But my question
remains, which bug are you asking about?  The bug in the firmware that hangs the
GPU?  Or the bug in DRM that crashes the system a few seconds after the GPU has
hung instead of responding in a useful manner?
On another note, I should mention that I have yet to find a way to upload
attachments to bugzilla using lynx(1), so please keep that in mind if you need
any further documentation beyond what Pau Amma posted here for me.  If
necessary, I can probably email whatever may be needed to a requesting party.
Comment 6 Niclas Zeising freebsd_committer freebsd_triage 2020-07-16 11:20:31 UTC
(In reply to Scott Bennett from comment #5)
I am referring to the problem you have of running a FreeBSD gui.  Has that been fixed with recent updates in the graphics stack?  Is this issue still relevant?
From the logs from pauAmma, I see you are still using 1.18.4, that has been updated.  The drivers have also been updated, and if you are running current you can try drm-devel-kmod, which is the development version of the drivers.

Speaking of GUI, you should be able to use scfb (if using EFI boot) or vesa to get a working, but software accelerated GUI.  That should be enough to get browsing going, for instance.
Comment 7 Newton Terry 2020-07-16 15:49:53 UTC
(In reply to Scott Bennett from comment #5)

> On another note, I should mention that I have yet to find a way to upload
> attachments to bugzilla using lynx(1)

Doesn't "Enter path to the file on your computer" work?

Alternatively you can "Paste the text to be added as an attachment". Take a look at https://lynx.invisible-island.net/lynx_help/keystrokes/edit_help.html , "Editing Keymap" , "Insert file in textarea".
Comment 8 Scott Bennett 2020-07-17 10:33:05 UTC
     I don't have a problem running a graphical browser per se.  As stated in
my original description I have a problem with two things:  1) the GPU hangs in
under 35 hours and 2) the driver, instead of doing something rational like
reinitializing the GPU and restoring the screen image, crashes the system
without so much as a sync().  Such a combination is actually much worse than
useless.
     The GPU hang, I presume, is due to a bug in the firmware modules loaded by
the DRM driver, which is radeonkms.ko in this case.
     My machine is running 11.4-PRERELEASE r360432.  I have postponed updating
to the 12.-STABLE version that finally built successfully under the present
system.  There is presently no justification for an upgrade's lost time when
there is no production version of FreeBSD available and security patches are
still being made available for the experimental versions that are available,
including the version listed in the previous sentence.  Unfortunately, I
naively updated beyond the 11.1 to 11.2 boundary and upgraded my pools, so I
had left myself no way to return to 11.1, the last production release of
FreeBSD.  11.1, is no longer available for production use because no security
patches patches for it are made available since it reached EOL years ago.
Comment 9 Niclas Zeising freebsd_committer freebsd_triage 2020-07-17 11:18:54 UTC
(In reply to Scott Bennett from comment #8)

As long as you are running unsupported FreeBSD versions, there is not much I can do.  FreeBSD 11.4-PRERELEASE is not a supported version.  I suggest you either run FreeBSD 11.4 or better yet 12.1, both are supported.  You can also run the latest 11-stable or 12-stable, or 13-current.

I don't know why your GPU hangs, however, there has been a lot of development both in the FreeBSD base system as well as the various ports that is the graphics stack.  I asked if this was a problem with an updated FreeBSD version, and updated components.  The log you have pasted is from xorg-server 1.18, which has been replaced, so I'm asking again:

Is this a problem with FreeBSD 12.1 using drm-fbsd12.0-kmod and the latest version of gpu-firmware-kmod?  Have you tried FreeBSD current with drm-devel-kmod?

I do not know what you mean by "there are no production versions of FreeBSD", currently, the supported releases are 11.3 (that will go EOL soon), 11.4 and 12.1.  12.2 is planned to be released later this year.  Both 11.2 and 11.1 are EOL, since quite some time.
Comment 10 Scott Bennett 2020-07-17 18:21:53 UTC
     I had not been aware that a stable/11 revision became unsupported in under
80 days.
     11.2+ and 12 have kernel bugs in memory management that necessitate
reboots every few days to return the system to usability.  That time period can
be extended if the kinds of things run on the system are very limited and
some sysctl variables are properly tweaked.  However, whether sooner or later,
a reboot is necessary.  For example, since my most recent reboot, the system
has remained up for a bit over 28 days, but it will have to be rebooted soon
because the pagedaemon is taking 60% to 100% of one core in searching for page
frames it can return to the free list because the free list has finally dropped
below 410 MB, the amount I set vm.pageout_wakeup_thresh because it appears to
be the minimum necessary for the kernel to start paging in a process that has
been marked a swapped out, even something as small as /bin/sh.  An OS that
needs a reboot every few days (usually between 3 and 9) is not a production
version by any stretch of the imagination.  We lived with such things in the
1960s, but things were also expected to be better in the future.  They *were*
better for quite a while, but apparently FreeBSD has reversed course in that
respect.
     As for your questions, I thought my previous response was clear enough,
but then, I thought my original description was, too.  Apparently, neither was.
I have not, at present, any reason good enough to justify the lost time to do
an upgrade to 12.1, whether -RELEASE or -STABLE.  Has there been any change to
gpu-firmware-kmod for stable/11 since 28 April 2020?  If not, then I would
expect the GPU hangs to remain a problem.  If so, please advise, and I will
rebuild gpu-firmware-kmod.  Has radeonkms.ko had any changes to how it is
intended to respond to a GPU hang?  If the GPU hangs may have been fixed, then
it may not matter so much whether DRM has been fixed, at least until the next
GPU-hanging bug is introduced into firmware for a card.  If the firmware is
still buggy, but DRM's response may have changed, then I will try it.  If not,
then there appears to be no reason for me to waste the time on it.
     So please do let me know whether each port has been updated in a way that
may help.
     I have never run -CURRENT and don't intend to do so unless conceivably in
a VM.  I only have one functional machine.  By today's standards it is now
slow, so I don't want to divert it very much from the work I have it doing.
Comment 11 Alexey Dokuchaev freebsd_committer freebsd_triage 2020-07-20 06:59:34 UTC
(In reply to Niclas Zeising from comment #9)
> As long as you are running unsupported FreeBSD versions, there is not much
> I can do.  FreeBSD 11.4-PRERELEASE is not a supported version.
And what exactly had changed in between 11.4-PRERELEASE and 11.4-RELEASE graphics-wise?  It always saddens me to see these "ah, you're running prerelease version" or "sorry, support for version X.Y had ended yesterday, please update to newer version" phrases, like it would make a difference (pro tip: no, it won't).

> I suggest you either run FreeBSD 11.4 or better yet 12.1, both are supported.
Unless we're talking about some specific changes, simply switching to 11.4 or 12.1 would most likely not magically make things better all of sudden.  radeon(4) cards, which used to work before, are currently broken in FreeBSD, and that raises two questions: 1) what had caused the breakage, and 2) how to fix it.  AFAIK, there are no answers for both of them ATM.

> I don't know why your GPU hangs, however, there has been a lot of development
> both in the FreeBSD base system as well as the various ports that is the
> graphics stack.
Tests I've done couple of months ago, trying various combinations of FreeBSD 13-CURRENT base and different drm-kmod drivers did not show any improvements; that is, I was not able to get back the experience of ca. 2017-2018 where radeon(4) cards have been working fine on FreeBSD.
Comment 12 Scott Bennett 2020-07-20 11:15:45 UTC
     FWIW, I just updated my stable/11 source tree and started a buildworld.
It should be done in several hours.  When I'm next awake after it has finished,
I'll start the buildkernel.  However, I will need to wait for a good time for
installing and rebooting, etc.  In light of Alexey's comment I would rather not
take the system down until it really needs it, however.  (Setting
vm.pageout_oom_seq=1024000 seems to have postponed the anticipated need to
reboot the other night by eventually scrounging up enough page frames for the
free list to let it keep going.  pagedaemon now has a total CPU time of 6.5 to
7 hours on it.)  Anyway, I want to thank Alexey for taking the time to confirm
that Radeon support is buggy on more than just my system.  AFAIK, he did that
of his own initiative.  And I do notice that he asked Niclas the same questions
that I did.  I am still hoping to see answers to them because they may
determine whether there is yet sufficient reason to go through the hassle of
moving to stable/12.  Without them there certainly is not.
Comment 13 Warner Losh freebsd_committer freebsd_triage 2020-07-20 15:38:54 UTC
The graphics drivers are highly sensitive to many things most other drivers are not. There's enough churn, even in stable, in the parts of the kernel that matter the graphics team is unable to provide much, if any, support for non-released versions of FreeBSD (plus very recent current and stable branches). There's simply not the resources there to chase down all the variants. Maybe there is something different, maybe not, in the 11.4-PRERELEASE, maybe it will work, maybe not, but the resources in the graphics team aren't such that they can provide support.

It's unfortunate, since many other drivers just work unless there's some specific bug fix missing. However, given the wide variety of cards, and the historic sensitivity of the code, it's better to communicate the limits than to suggest the graphics team can help with old versions of FreeBSD. In conversations with the team, I know they'd like to have enough resources to help everybody. Given the size of the team, speed of API changes in -current and Linux, it's hard to find the time.
Comment 14 Scott Bennett 2020-07-21 04:35:12 UTC
     Warner, I guess I need to correct my previous statement that Alexey had
asked the same questions I had.  My questions were rather more general than
his.  I asked, "Has there been any change to gpu-firmware-kmod for stable/11
since 28 April 2020?" and "Has radeonkms.ko had any changes to how it is 
intended to respond to a GPU hang?"  Surely the first question is easy enough
for anyone on the x11 team to answer.  The second one would likely take a bit
closer look at the update log for radeonkms.ko, but it also might be as simple
as seeing that there were no changes made at all during the time period in
question.  IOW, there ought to be no problem in answering the questions I had
asked, and it also I ought to take no more than a few minutes at worst to find
the answers and tell me.  If there is no difference in a module between two
dates, then updating to the current date should naturally be expected to be a
waste of time in terms of finding solutions to the problems.
     There is now a new obstacle for me.  My stable/11 "make buildworld" ran
to many hours, finally finishing about 7:15 p.m.  llvm continues to grow at an
alarming rate, so now it takes longer to build it than all the rest of FreeBSD
combined.  I then ran buildkernel, which ran almost to completion, but failed
near the very end due to large numbers of compilation errors from having
uncommented "options EVDEV_SUPPORT" because it is supposedly now required and
there is now supposedly a way to continue to use moused with it enabled.  So
next I will try updating to tonight's source tree and run it all again.  If I
don't see any changed modules that look like they might have anything to do
with EVDEV_SUPPORT, then I will look again tomorrow and, if necessary, repeat
each day or two until I do see such and then will try building world and kernel
again.  Until then, I don't see the need to waste processing time.
     I reiterate that I have not asked whether the problems in
gpu-firmware-kmod of drm-fbsd11.2-kmod have been fixed.  I have asked whether
the particular modules supporting a Radeon HD 5770 have even been changed
since 28 April 2020.
     Warner, I also have a parting question for you, raised by Niclas.  For how
many days is a particular stable/11 or stable/12 revision considered to be
supported?
Comment 15 Alexey Dokuchaev freebsd_committer freebsd_triage 2020-07-21 06:31:10 UTC
(In reply to Warner Losh from comment #13)
> The graphics drivers are highly sensitive to many things most other drivers
> are not.
Could you elaborate a bit more on this?  When DRM bits were in the base, FreeBSD had offered awesome graphics experience, despite that it was claimed those bits were actually not maintained very well.  That was just 2-3 years ago, then we started to deteriorate rapidly.  What had changed?  Why did we allow it?  Why no one waived the red flag?

> There's enough churn, even in stable, in the parts of the kernel that matter
> the graphics team is unable to provide much, if any, support for non-released
> versions of FreeBSD (plus very recent current and stable branches).
This just means that there's bad communication and coordination of development efforts between the graphics team and src team.  In other words, our process sucks (that's how our users see it).

> Maybe there is something different, maybe not, in the 11.4-PRERELEASE, maybe
> it will work, maybe not
Well, these "maybenots" make us look pretty bad, that's for sure.  I keep receiving emails about more users switching from FreeBSD to GNU/Linux precisely because of lack of focus and uncertainty even among developers themselves.
Comment 16 Niclas Zeising freebsd_committer freebsd_triage 2020-07-21 07:24:57 UTC
(In reply to Scott Bennett from comment #14)
EVDEV_SUPPORT (or any evdev related kernel options) are not supported on 11.  There is a reason they are not in GENERIC.  They are not needed on 11, however, the handling of input devices will not be as good as on 12 or later (things like advanced touchpad features, hotplug and so on might not work).
Comment 17 Niclas Zeising freebsd_committer freebsd_triage 2020-07-21 07:49:19 UTC
(In reply to Alexey Dokuchaev from comment #15)


(In reply to Warner Losh from comment #13)
>> The graphics drivers are highly sensitive to many things most other drivers
>>  are not.
> Could you elaborate a bit more on this?  When DRM bits were in the base,
> FreeBSDhad offered awesome graphics experience, despite that it was claimed
> those bits were actually not maintained very well.  That was just 2-3 years ago,
> then we started to deteriorate rapidly.  What had changed?  Why did we allow it?
> Why no one waived the red flag?

FreeBSD did not have a great graphics experience 2-3 years ago, not with the code in base at least.  The code in base (now called drm-legacy or legacy drm or drm2) was never well supported by the project after being imported.  This showed in lack of updates, and generally bad support for modern hardware.
The source was ported and imported around 2012, and then updated to eventually mostly match what was in Linux 3.8, several years later.  This meant that hardware support ended with Haswell, a CPU from 2013.  On the AMD side, I am not exactly sure where support ends, but amdgpu.ko does not exist in drm-legacy, which is needed to support things more recent than around HD7700-series, released in 2012 (according to Wikipedia).

In the meantime, things moved on, both in the userland parts of the graphics stack, as well as the kernel drivers (drm-legacy doesn't support dri3, as an example), and FreeBSD lagged further and further behind.  It was not possible to buy reasonably new hardware hand have it work as a desktop, for instance.

drm-legacy had been a full port of the graphics drivers in Linux, meaning that all kernel interfaces (mostly VM stuff) had to be rewritten.  This made porting new versions of the driver quite hard, from my understanding, and also made maintenance hard (apart from keeping the driver compiling, maybe).

To remedy this, and to ease with further porting and updating, the new version of the driver was made to use the linux kpi interface in FreeBSD (this already existed, but was extended).  This made it easier to update the driver, as all shims needed lived in one place, and could be reused, making the diff of the driver against the Linux upstream much smaller and more manageable.  At the same time, to ease development effort, and because of licensing issues, the driver was moved outside the FreeBSD source tree.  This meant we could deliver updates and bug fixes much faster to users, no need to wait for releases or erratas, for instance.  It also made it easier for developers not being FreeBSD committers to contribute.  Without these efforts, support for graphics on FreeBSD would most likely had ended with Haswell, and radeonkms.ko, and the FreeBSD project would be even less relevant in the desktop segment.

As for deteriorating, I do not at all agree.  On the AMD side, things are a little less stable, and certain GPUs are having some issues, especially older GPUs, from the bug reports we get.  However, I'm running FreeBSD as a desktop across two different laptop models, as well as a desktop, and I know several other laptop models that work without issues.  With CURRENT and drm-devel-kmod we even support the very latest gen10 Intel CPUs, as well as recent AMD GPU offerings, something that was simply not possible with drm-legacy.

The support matrix for graphics hardware is enormous.  We can not test on every single GPU out there, that is simply not feasible.  We in the Graphics Team try our best to test on a variety of hardware, but sometimes, there will be regressions.  At some point we also need to move forward, to keep up with upstream, both on the userland and kernel side.

>> There's enough churn, even in stable, in the parts of the kernel that matter
>> the graphics team is unable to provide much, if any, support for non-released
>> versions of FreeBSD (plus very recent current and stable branches).
> This just means that there's bad communication and coordination of development
> efforts between the graphics team and src team.  In other words, our process
> sucks (that's how our users see it).

No, this means that this is extremely complex.  Support for old STABLE (and CURRENT) revisions have always been best-effort.  If you are tracking the development branches, you have to keep up.  While there are no fixed lines, for graphics we try to keep the support window a couple of months, but that's not always possible.
Comment 18 Scott Bennett 2020-07-22 17:38:02 UTC
     With "options EVDEV_SUPPORT" once again commented out, buildworld and
buildkernel completed normally.  I'm now waiting for an appropriate time to
installkernel, reboot, installworld, reboot, etc.  I am also waiting for an
answer to the two questions I asked to find out whether there is any point in
doing the update at this time.  The update would bring my system up to r363403
of stable/11, whereas it is presently running r360432.  Niclas, because r363403
is from early a.m.--FreeBSD now takes a ridiculous amount of time to build,
mainly due to llvm--do you consider it unsupported already?
Comment 19 Scott Bennett 2020-08-06 13:33:03 UTC
     I have now been running
FreeBSD hellas 11.4-STABLE FreeBSD 11.4-STABLE #26 r363403: Wed Jul 22 02:34:08 CDT 2020     bennett@hellas:/usr/obj/usr/src/sys/hellas  amd64
for 7:39AM  up 4 days, 22:44 plus the time it will take to post this message.
     Niclas has not yet answered my two yes/no questions originally asked here
on 17 July 2020.  However, since then I have answered the second one myself by
running portmaster graphics/drm-fbsd11.2-kmod and seeing that it rebuilt and
reinstalled the same version of the port after an svn update /usr/ports.  I do
not have the same answer for graphics/gpu-firmware-kmod because I neglected to
run it under script(1) in single-user mode.  As of the time and date I
installed the OS upgrade and reinstalled drm-fbsd11.2-kmod, there had been no
change to the latter since 28 April, which means that the drm bug hasn't been
touched since then.  If I can please get an answer to my question about changes
to gpu-firmware-kmod during that same time period, then we will know whether
anything has been done there, too.
     On 21 July, another point was raised by Niclas, so I asked it here of
Warner.  To date, I have seen no answer to that question either.  I do want to
know that answer because it might give me some idea how many more times I might
be told to update (again) to a "supported" revision or go away before I decide
that going away is the only remaining option to get to a system with usable
graphics.  I've been without usable graphics under FreeBSD off and on since I
started using FreeBSD 5.2.1 in 2005 with the "off" periods lasting from months
to *years* at a time.  This time has been going on for months already.  If I
had wanted a system for character terminal use only, I would gotten something
with an RS232 port and tracked down an old VT100 or the like.
     Lest Niclas still not understand, a) I do not like having my system crash,
leaving a mess to clean up manually and get everything restarted, b) there is
no reason to test again software that has not changed, so I won't do that, and
c) abandoning this discussion solves nothing, improves nothing, and frustrates
immensely.
Comment 20 Scott Bennett 2020-09-21 03:24:10 UTC
     Another month and a half has ticked by with no response and no action.  
Meanwhile I have further upgraded my system to
FreeBSD hellas 11.4-STABLE FreeBSD 11.4-STABLE #27 r364474: Sat Aug 22 22:59:43 CDT 2020     bennett@hellas:/usr/obj/usr/src/sys/hellas  amd64
and expect to update again in the next few days.
     I recently borrowed a laptop and installed NomadBSD onto an external USB
hard drive.  It seems to work well and doesn't crash, although something
initially dims the screen until the screen is unreadable except in a pitch black
room.  To counter that, I added a "/usr/local/bin/xset -dpms standby" line to
.xinitrc, so that it puts the screen into standby, at which point I can hit any
key or move the trackball, which turns the screen back on at normal brightness.
It does require logging in and then entering startx in the blind, but at least
it is then usable.
      But, to get back to the topic of this ticket, I would just like to say
that it would be nice to have a usable, safe graphics stack to use with FreeBSD
on this tower machine.  It would also be nice not to continue to be ignored
w.r.t. this PR.
Comment 21 Niclas Zeising freebsd_committer freebsd_triage 2020-09-21 10:55:06 UTC
(In reply to Scott Bennett from comment #20)

Hi!
I am not sure exactly what else you expect.
You are expected to run a supported version of FreeBSD.  Currently, that's 11.3, 11.4 and 12.1.  11.3 stops being supported at the end of September.  We also try to support the latest STABLE and CURRENT branches, but if you are using those branches, you are expected to keep up with development, and to upgrade in a timely fashion.

When it comes to graphics, we try to support everything that Linux supports when it comes to AMD/ATI and Intel GPUs (nVidia is providing binary drivers, so I have to refer to them for support for nVidia GPUs).  However, the graphics team is a small team, and it is mostly a volunteer effort, which means that it is impossible for us to test every combination of hardware and software, and especially for older GPUs, there might be regressions, both in FreeBSD and imported from Linux (the GPU drivers for Intel and AMD/ATI comes originally from Linux).

I'm sorry that you feel you've had a sub-par experience wrt. graphics on FreeBSD.  At the same time, I must say that I don't share your experience.  I've been using FreeBSD on a desktop for over a decade without much issue, and I use FreeBSD as a desktop OS on a daily basis.

gpu-firmware-kmod is regularly updated, when there is new firmware.  I cannot, however, tell if it is relevant for your GPU.  Generally, it is firmware for more modern ATI/AMD and Intel GPUs that are updated.  The firmwares are provided by Intel and AMD, and pulled in from the Linux firmware repository.

I don't know much about NomadBSD, haven't used it myself.  But if it works for you, then, by all means, use it.  I note that NomadBSD is based on FreeBSD 12.1.  FreeBSD 12.1 (and the upcoming 12.2) uses a more recent version of the gpu-kmod driver, based on Linux 4.16.  There have also been a lot of changes to the Linux KPI compat layer between FreeBSD 11 and 12.  If NomadBSD works, perhaps the problems you are experiencing have been solved.

I have been quite patient in trying to help you, explain the situation and solve the issues, and I've spent a lot of time replying to you here.  However, if all you are going to do is complain and rant, I am less inclined to help.  Remember that we are all volunteers, working on FreeBSD and FreeBSD Graphics in our spare time.

Regards
Niclas
FreeBSD Graphics Team
Comment 22 Scott Bennett 2020-09-25 04:30:45 UTC
>I am not sure exactly what else you expect.

     I expected at minimum an answer to yes/no questions (see comment #10).

>You are expected to run a supported version of FreeBSD.  Currently, that's
>11.3, 11.4 and 12.1.  11.3 stops being supported at the end of September.  We
>also try to support the latest STABLE and CURRENT branches, but if you are
>using those branches, you are expected to keep up with development, and to
>upgrade in a timely fashion.

     And there you dodge the questions in comments #10, #14, #18, #19, and #20
again.  Have the firmware modules changed since 28 April 2020?  How long are
stable revisions considered to be adequately up to date to be supported?

>I don't know much about NomadBSD, haven't used it myself.  But if it works for
>you, then, by all means, use it.  I note that NomadBSD is based on FreeBSD
>12.1.  FreeBSD 12.1 (and the upcoming 12.2) uses a more recent version of the
>gpu-kmod driver, based on Linux 4.16.  There have also been a lot of changes to
>the Linux KPI compat layer between FreeBSD 11 and 12.  If NomadBSD works,
perhaps the problems you are experiencing have been solved.

     Obviously irrelevant.  NomadBSD is running on a laptop's AMD APU.  The
problems are occurring on a tower with a Radeon HD 5770 card made by MSI.
     It's worth noting that the condescension of your final paragraph is off-
target, as well as moderately offensive.  I do, of course, understand that you
are a volunteer.  However, if you are unwilling or unable to support the Radeon
HD 5770, then you should either state that up front or perhaps try to find
another team member who is willing and able to support it.  Dodging questions
and hoping the problem will just go away is not being patient or helpful.
     More than two months ago you instructed me to repeat something that was
already known to fail with those versions of the firmware and DRM module.
Because that seemed a pointless thing to do, I asked whether a) the firmware
had changed or b) radeonkms.ko had changed.  I later answered the radeonkms.ko
question in the negative.  I still do not know about the firmware.  I also
asked in various ways how recent a revision of a STABLE branch of FreeBSD was
considered sufficiently recent to be supported.  I am still waiting to get the
answers to those two questions.  If either has changed since 20 April 2020,
then I will certainly try running xorg again.  Until then, I cannot see a reason
to crash my system deliberately by running versions that have been proven to
fail.  It really is a simple and obvious decision to make.
Comment 23 Scott Bennett 2020-12-21 19:06:18 UTC
     Four days ago I upgraded my system to stable/11 r368269 and then rebuilt
and reinstalled gpu-firmware-kmod and drm-fbsd11.2-kmod.  I then rebooted,
logged in, rebuilt and installed windowmaker, and then entered "startx".  The
screen went black, and about 11 seconds later the system did a hard BIOS reset.
Apparently, there is no longer *any* support for a Radeon HD 5770, even though
older cards *are* supported, at least according to other posters on this and
other lists.
     The following messages appear in /var/log/messages immediately before the
beginning of the messages from the reboot.

Dec 17 13:15:45 hellas kernel: drmn0: ring 0 stalled for more than 10498msec
Dec 17 13:15:45 hellas kernel: drmn0: GPU lockup (current fence id 0x0000000000000008 last fence id 0x000000000000002b on ring 0)

      Thus it is clear that neither the firmware bug nor the DRM bug has been
corrected in more recent versions of those modules.  Doesn't the x11 team
report firmware bugs to AMD?  Doesn't the x11 team report DRM bugs upstream to
whoever is developing/maintaining X11 for LINUX or for whatever?  If so in
either case, does any response come back to the x11 team?  Has either bug yet
been reported upstream?  Pau Amma kindly first filed this PR on my behalf six
months ago, and I have seen no sign of any resolution, except for mantras to
spend lots of money.
     As far as I can tell, spending on another GPU is not the answer.  A new
GPU is likely not to be supported yet or become unsupported within four or five
years, leaving a very narrow window during which it would actually be useful,
making that a very poor investment of scarce resources.
Comment 24 pr 2020-12-22 09:40:30 UTC
Dear Scott,
you, like many other, are just the innocent victim of a FreeBSD documentation bug.

FreeBSD does not support graphics. Period.

The project is at the "proof of concept" level, nothing more. Do yourself a favor and stop investing time in this: when you report a problem in the graphic subsystem in the best case it will be ignored. In the worst case you will get misleading information (like "try this, do that") that keeps you busy for months, but there is no solution at sight. Look at this pr: reported in June (6 months and 2 days ago), current status: open. Come back in another 6 months it will either be dead or still open.

"Understaffed" is the apparent condition, the true reality is that FreeBSD is just not meant for desktop users. Too many have spent long hours, efforts, energy and sometime also money fighting windmills to promote graphic use in FreeBSD. I urge you to learn there other have failed and take it from there: look elsewhere.

A few facts that can help you understand how big is this documentation bug:
1) sys/dev/drm2/radeon/radeon_drv.c, line 123 reads:
int radeon_audio = 0;

For the sake of completeness, this same line is line 158 for Linux users
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/radeon/radeon_drv.c and reads:
int radeon_audio = -1;

This means that audio is not going to work on any Radeon card with FreeBSD. It has been like this ever since, and it's a "workaround" so that developers have the time to run the "proof of concept" show without having to deal with minor details such as having FreeBSD produce noise out of your speakers. Watching a video is enough, why would anyone want to hear it as well?

2) On Radeon, if you want to boot with drm driver, you have to disable the console, and see nothing during the boot. You cannot boot in single user mode (I mean, you could, but with a black cursor on a black screen), should you need to fix anything. This is acceptable for a "proof of concept" but definitely not for a production system.

This has been like this for years now, rest assured it will stay like that.

3) If you happen to be a programmer willing to help there is no documentation that can guide you trough your process. You either are a FreeBSD master (e.g. buy a course from McKusick) or you will very likely find yourself staring at a hung screen. Don't look for a tutorial or a guide. Those who have the knowledge are too busy running the "proof of concept show" (did I state this already?) to write something down and help others make their way trought.

4) Should you manage to reach the magic point (an alchemy of hardware and software mix) where you can run clinfo you will get a core dump. vlc? Hangs on the second video (remember, still no audio). Don't use VAAPI, just don't, ok? Chromium (sorry, Chrome is not supported) requires 875 patch files (not lines, files) to build, so don't expect it to work: it's just another proof of concept.

5) Yes, I could go on, I think this is enough for you to open your eyes.

I have been in the FreeBSD ecosystem for a few decades now and saw too many falling apart when they hit the graphic subsystem not to spend a few minutes and warn you about this important documentation bug.

My recommendation is to switch to some Linux distro for production. Any crappy Linux (sorry for the redundant terms) would do, it just delivers what FreeBSD is unable to and it works out of the box with your current hardware.

And remember to tell your friends that FreeBSD does not support graphics. Now you know.

Regards,
Comment 25 Vladimir Kondratyev freebsd_committer freebsd_triage 2020-12-22 12:43:20 UTC
(In reply to pr from comment #24)
> A few facts that can help you understand how big is this documentation bug:
> 1) sys/dev/drm2/radeon/radeon_drv.c, line 123 reads:
> int radeon_audio = 0;
> For the sake of completeness, this same line is line 158 for Linux users
> https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/radeon/radeon_drv.c and reads:
> int radeon_audio = -1;

Please, do not confuse people with comparing apples and oranges.

Linux driver, corresponding to our deprecated base version (v3.8), also has radeon_audio set to 0:
https://github.com/torvalds/linux/blob/v3.8/drivers/gpu/drm/radeon/radeon_drv.c#L144

While current FreeBSD driver has radeon_audio set to -1:
https://github.com/freebsd/drm-kmod/blob/5.4-lts/drivers/gpu/drm/radeon/radeon_drv.c#L193

I don't know, if it works though.
Comment 26 George V. Neville-Neil freebsd_committer freebsd_triage 2020-12-22 21:30:55 UTC
(In reply to pr from comment #24)

Comments such as this are both incorrect and unhelpful.  Please be considerate of the team that is doing this work and post your vitriol elsewhere.
Comment 27 Emmanuel Vadot freebsd_committer freebsd_triage 2021-11-19 15:19:40 UTC
FreeBSD 11 isn't supported anymore, closing.
Comment 28 Scott Bennett 2021-11-20 07:18:39 UTC
     My questions remained unanswered by the time this was closed.  In the
comments made by manu@ when closing quite a few other PRs on 19 November 2021,
he appears to disagree with the FreeBSD project's web site, which says that
FreeBSD 12.2 is still a supported release.  Perhaps he should either change the
web site or change his comments.
     Although this PR ended being closed in the manner I had expected, it was
another example of a PR being dispensed with in a thoroughly unprofessional 
way.
Comment 29 Graham Perrin freebsd_committer freebsd_triage 2021-11-20 14:15:40 UTC
(In reply to Scott Bennett from comment #28)

Did you not try 13.0-RELEASE?
Comment 30 Alexey Dokuchaev freebsd_committer freebsd_triage 2021-11-28 00:40:18 UTC
(In reply to Graham Perrin from comment #29)
> Did you not try 13.0-RELEASE?
And what makes you think this would improve anything?  E.g. I've recently updated my fresh -CURRENT and thus had to rebuild DRM ports.  The one I'm supposed to use, based on Linux 5.4, had broken laptop resume from S3 for me (once again).  Then I've tried to build `graphics/drm-fbsd12.0-kmod' like I did before, but now the codebases had diverged far enough so it would require non-trivial patching to get Linux 4.16 DRM bits on recent -CURRENT.  So updating made things *worse* for me (breaking resume), not better.

FWIW, I've had to agree on what Scott had said in comment #28, bugs filed about graphics stuff typically sit there with no research or resolution only to be closed later as "overcome by events" (wtf?), that's why I stopped filing X11-related PRs.
Comment 31 Graham Perrin freebsd_committer freebsd_triage 2021-11-28 05:06:03 UTC
(In reply to Alexey Dokuchaev from comment #30)

CURRENT is not release engineered.
Comment 32 Scott Bennett 2021-12-03 07:06:16 UTC
In reply to Graham Perrin in comment #29:
     No, I have not tried 13.0 on my tower, nor do I plan to do so.  Having
actually learned from long and often hard experience, I avoid .0 releases of
most software and especially operating system software.  Also, I just took
advantage of some free time over the holiday weekend to upgrade FreeBSD on this
system from 11.4-STABLE to 12.2-RELEASE and am still reinstalling packages and
ports, so please allow me some time to complete that process and to catch my
breath a bit. :-}
     Once all that has been done, I will try running xorg both with and without
scfb to see what happens.  Quite unexpectedly, I received a hand-me-down at the
T-Day family gathering, a Radeon HD 6970 card.  After I see whether upgrading
has made any difference in gpu-firmware-kmod's behavior or drm-kmod's behavior,
I will replace the Radeon HD 5770 card with the Radeon HD 6970 card and then
try that card both with and without scfb.  My prediction regarding drm-kmod is
that there is no change that will affect the situation of a hung GPU.  As far
as basic, console-mode support for gpu-firmware-kmod is concerned, I suspect
that that will work okay, but whether it, too, will crash within 35 hours is
concerned, I have no idea, but it will be an interesting set of experiments to
run.
     Meanwhile my system is running 12.2-RELEASE without xorg, but also without
obvious problems, other than the previously described memory management
problems, which, I admit, I have not had much time to explore yet, although I
have seen some evidence already that at least some are still present in the
12.2 kernel.  12.3 is due to be released in the next few days, and then I will
have the same problems to explore all over again.  As usual, I expect to wait a
week or two after the release for early problems to be fixed before I proceed
with that upgrade.  Adding to my projected time frame are things like overdue
ZFS pool scrubs, pool upgrades, etc.
     I want to add some thanks here to Pau Amma, who so kindly posted this PR
for me last year.
Comment 33 Mark Linimon freebsd_committer freebsd_triage 2021-12-07 14:50:08 UTC
(In reply to Alexey Dokuchaev from comment #30)
> bugs filed about graphics stuff typically sit there with no research or resolution only to be
> closed later as "overcome by events"

Like many things in FreeBSD, there is far more demand for support than there is supply of people
who have the time to do the work.

Thus, when someone eventually tries to prune stale things out of the PR database, they get
criticized instead of thanked.  This is one reason why I strongly suggest to new bug triagers
"do not start with the oldest PRs.  You will mostly get negative feedback, and that leads to
burnout".

It's also why I do not try to do such work myself, any more.

mcl
Comment 34 Scott Bennett 2021-12-19 06:03:06 UTC
     In the past few weeks I have upgraded FreeBSD from source on my tower from
11.4-STABLE to 12.2-RELEASE and then re-installed ports preferentially from
2021Q4 packages, but building from ports where necessary (portmaster -P).  Note
that graphics/gpu-firmware-kmod and graphics/drm-fbsd12.0-kmod were both
installed from ports.  Using the virtual terminal mode with radeonkms.ko 
loaded worked, though with the same sorts of colorful screen artifacts as were
present under 11.4-STABLE.  Attempting to run xorg with radeonkms.ko resulted
in a kernel panic after 10 to 20 seconds.  Attempting to run xorg with
radeonkms.ko loaded and scfb specified as the driver to use resulted in some
configuration steps occurring, followed by xorg shutting down.  IOW, the result
is that I had no support at all in 12.2-RELEASE.
     A few days ago following a hung system due to power fluctuations, I did
the upgrade to 12.3-RELEASE, also from source, and then rebuilt both
gpu-firmware-kmod and drm-fbsd12.0-kmod.  When using virtual terminals, there
are now somewhat less frequent screen artifacts thus far, but there are still
plenty of them.  Attempting to run xorg with radeonkms.ko resulted in xorg
going through much of the normal configurations steps, followed by xorg
shutting itself down.  Attempting to run xorg with radeonkms.ko loaded and the
scfb driver specified resulted in a much abbreviated set of configuration steps
and a shutdown.  12.3-RELEASE appears to have no functional graphics support
either.
     Both 12.2-RELEASE and 12.3-RELEASE are allegedly "supported" releases of
FreeBSD at this time.  Is there any possibility that the X11 team believes that
these releases are supposed to be supported at present?
     The xorg log files from the two experiments described above under
12.3-RELEASE are available, but I cannot seem to post them with lynx(1), and
because I have no functioning graphics at present, I cannot use a graphical web
browser to upload the log files.  Also, I believe this PR should be reopened
now that it once again involves supposedly supported releases of FreeBSD.
Comment 35 Graham Perrin freebsd_committer freebsd_triage 2021-12-19 09:07:58 UTC
(In reply to Scott Bennett from comment #34)

> … 12.2-RELEASE 2021Q4 packages … 

Noted. 

> graphics/gpu-firmware-kmod and graphics/drm-fbsd12.0-kmod were both
> installed from ports. 

Which branch?

> kernel panic 

If you allowed the system to save the core dump, please attach relevant information to a separate bug. Thanks.
Comment 36 Graham Perrin freebsd_committer freebsd_triage 2021-12-19 10:00:03 UTC
(In reply to Scott Bennett from comment #34)

> … 𡀦12.2-RELEASE and 12.3-RELEASE are allegedly "supported" … supposed …

Factually
=========


12.2-RELEASE, 12.3-RELEASE and 13.0-RELEASE are: 

* release engineered
  <https://docs.freebsd.org/en/articles/freebsd-releng/>

* supported
  <https://www.freebsd.org/security/#sup>
  <https://www.freebsd.org/security/#model> NB the rationale.


Compared to 12.⋯: 

 * 13.⋯ and 14.0-CURRENT allow superior DRM. 


stable/13 can be used with: 

* graphics/drm-fbsd13-kmod
  <https://www.freshports.org/graphics/drm-fbsd13-kmod/>

* graphics/drm-devel-kmod 
  (DRM currently superior to graphics/drm-current-kmod)
  <https://www.freshports.org/graphics/drm-devel-kmod/>.


More on support: 

* <https://forums.freebsd.org/posts/547353>

– in particular: 

> merges to stable/12 are naturally less frequent than 
> merges to stable/13
Comment 37 Scott Bennett 2021-12-23 05:03:07 UTC
     I assume that the ports branch is whatever is the default for 
12.2-RELEASE.  How would I check to be sure?  I have not changed anything to
configure this that I know of.
     /etc/rc.conf has
dumpdev="/dev/ada0p13"
dumpdir="/var/crash"
No panic dumps have been saved by savecore(8) since late July 2020.
Comment 38 Scott Bennett 2021-12-23 05:06:27 UTC
     Yes, Graham, I am well aware of the project's view of support.  What I was
asking, in effect, was whether the graphics team concurs with the official
position of the FreeBSD project.  Earlier postings by at least one team member
seemed to suggest that the graphics team did *not* concur.
Comment 39 Warner Losh freebsd_committer freebsd_triage 2021-12-23 15:21:48 UTC
(In reply to Scott Bennett from comment #38)

The graphics team wishes it has the resources to support everything that the larger project supports. However, we could support older releases badly, but tell people they work. Or we could tell them that newer releases are much better tested and tend to work a lot better because that's where the graphics team has focused its limited resources. In the past, we've done the former and disappointed a lot of people. We're doing the latter now to be honest and to give better advise about what's know to work because the developers are using that. Until we have more resources, this is the best that can be done.
Comment 40 Chris Hutchinson 2021-12-23 17:24:42 UTC
(In reply to Warner Losh from comment #39)
In light of that. May I humbly suggest that rather than
leading users like Scott on. That graphics@ simply return
ENOTIME. IMHO all the energy and frustration that went into
this pr(1) could have been better spent doing *productive*
things instead -- especially if graphics@ is strapped for
resources/manpower.
Comment 41 Ed Maste freebsd_committer freebsd_triage 2021-12-23 20:32:38 UTC
(In reply to Chris Hutchinson from comment #40)
The headline of this issue refrences 11.4, which is not supported, and this issue was closed as OBE when 11.4 went out of support.

FreeBSD 12.2 (for a little while longer) and FreeBSD 12.3 are supported releases, but 13.0 really provides a better experience.

If there is an issue that can be reproduced on 12.3 or 13.0 and sufficient detail is available (such as a kernel panic backtrace) please submit a new PR with those details.