amd64 radeondrmkms near-invisble text

["John D. Baker" <jdbaker%mylinuxisp.com@localhost>]

I was recently gifted with a Dell PowerEdge 2850 (which might end up
being a white elephant, judging by this thread:

  http://mail-index.netbsd.org/tech-kern/2015/02/11/msg018393.html

but that's for later concern).

I set up an NFS root and netboot arrangement for it (its disks were
decommissioned with extreme prejudice before I got it, so it has no
drive trays either).  First booting i386 7.99.4, I hit the problem with
pcdisplay0/vga0 at isa0.  Rebooting with -c and disabling these, it
panicked with "cnopen: no console device".  This I tracked down to not
linking the firmware file into "/libdata/firmware/radeon/R100_cp.bin"
("/usr" is a separate NFS mount shared by all machines of the same
architecture).

When I next rebooted, I thought I'd forgotten to disable pcdisplay/vga0
again as the screen looked black except for the bright white cursor.
It was in the wrong place, though.  (The pcdisplay/vga0 hang puts the
cursor at the top left, but this time it was at the bottom, and some
ways away from the left edge.)

Looking closer, I could just BARELY see the text emitted by the various
rc scripts.  For some reason, when radeondrmkms attaches on this machine,
the framebuffer console white text is exceptionally dim--the green kernel
messages are invisible.

After confirming that this machine could run the amd64 port, I switched
it over to that (7.99.5), but the radeondrmkms dim-ness persists.  The
cursor is bright white, however, as I would expect normal text to be.

VGA text mode/BIOS/etc. and operation prior to radeondrmkms attachment is
normal.

NetBSD 7.99.5 (GENERIC) #221: Wed Feb 18 04:46:21 CST 2015
        sysop%yggdrasil.technoskunk.fur@localhost:/r0/build/current/obj/amd64/sys/arch/amd
64/compile/GENERIC
total memory = 6143 MB
avail memory = 5946 MB
[...]
Dell Computer Corporation PowerEdge 2850
[...]
acpivga0 at acpi0 (EVGA): ACPI Display Adapter
[...]
radeon0 at pci11 dev 13 function 0: ATI Technologies Radeon 7000/VE QY (rev. 0x00)
[...]
drm: initializing kernel modesetting (RV100 0x1002:0x5159 0x1028:0x016D).
drm: register mmio base: 0xdf5e0000
drm: register mmio size: 65536
radeon0: info: VRAM: 128M 0x00000000C8000000 - 0x00000000CFFFFFFF (16M used)
radeon0: info: GTT: 512M 0x00000000A8000000 - 0x00000000C7FFFFFF
drm: Detected VRAM RAM=80M, BAR=128M
drm: RAM width 32bits DDR
Zone  kernel: Available graphics memory: 2134630 kiB
Zone   dma32: Available graphics memory: 2097152 kiB
drm: radeon: 16M of VRAM memory ready
drm: radeon: 512M of GTT memory ready.
drm: GART: num cpu pages 131072, num gpu pages 131072
drm: PCI GART of 512M enabled (table at 0x0000000042A86000).
radeon0: info: WB disabled
radeon0: info: fence driver on ring 0 use gpu addr 0x00000000a8000000 and cpu addr 0x0xffff80006f53f000
drm: Supports vblank timestamp caching Rev 2 (21.10.2013).
drm: Driver supports precise vblank timestamp query.
radeon0: interrupting at ioapic0 pin 18 (radeon)
drm: radeon: irq initialized.
drm: Loading R100 Microcode
drm: radeon: ring at 0x00000000A8001000
drm: ring test succeeded in 1 usecs
drm: ib test succeeded in 0 usecs
drm: No TV DAC info found in BIOS
drm: Radeon Display Connectors
drm: Connector 0:
drm:   VGA-1
drm:   DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
drm:   Encoders:
drm:     CRT1: INTERNAL_DAC1
drm: Connector 1:
drm:   VGA-2
drm:   DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c
drm:   Encoders:
drm:     CRT2: INTERNAL_DAC2
drm: Connector 2:
drm:   DVI-I-1
drm:   HPD1
drm:   DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
drm:   Encoders:
drm:     CRT2: INTERNAL_DAC2
drm:     DFP1: INTERNAL_TMDS1
radeondrmkmsfb0 at radeon0
radeon0: info: registered panic notifier
radeondrmkmsfb0: framebuffer at 0xffff80006f940000, size 1024x768, depth 8, stride 1024
wsdisplay0 at radeondrmkmsfb0 kbdmux 1: console (default, vt100 emulation), using wskbd0
wsmux1: connecting to wsdisplay0
wskbd1: connecting to wsdisplay0


Has anyone else experienced anything like this?  I have only one other
radeon-equipped amd64 machine I've tried with a drmkms-enabled kernel
and it worked fine (although it refused to use resolutions above 1024x768
in X, when it's perfectly capable of 2048x1536 in UMS mode).

-- 
|/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645