[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
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?
(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?
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?
(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.
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.
(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.
(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".
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.
(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.
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.
(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.
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.
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.
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?
(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.
(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).
(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.
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?
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.
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.
(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
>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.
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.
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,
(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.
(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.
FreeBSD 11 isn't supported anymore, closing.
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.
(In reply to Scott Bennett from comment #28) Did you not try 13.0-RELEASE?
(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.
(In reply to Alexey Dokuchaev from comment #30) CURRENT is not release engineered.
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.
(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
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.
(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.
(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
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.
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.
(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.
(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.
(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.