re: i386 radeondrmkms results

[matthew green <mrg%eterna.com.au@localhost>]

> I made similar adjustments to my GENERIC-based kernel config.  This just
> amounted to commenting out the UMS "radeondrm" driver and un-excluding
> the "radeon*" and "radeondrmkmsfb*" drivers.  I already exclude "pcdisplay0
> at isa?" and "vga0 at isa?".  My sources are -current from approximately
> 201501091900Z.
> 
> The system is an IBM Thinkpad A31p with (reported by my UMS drm kernel):
> 
> [...]
> vga0 at pci1 dev 0 function 0: ATI Technologies FireGL Mobility 7800 M7 LX (rev. 0x00)
> wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation), using wskbd0
> wsmux1: connecting to wsdisplay0
> radeondrm0 at vga0: ATI Radeon LX RV200 Mobility FireGL 7800 M7
> radeondrm0: AGP at 0xe0000000 64MB
> radeondrm0: Initialized radeon 1.29.0 20080613
> [...]
> 
> Booting the resulting drmkms-enabled kernel produced a panic in "cnopen()"
> claiming "no console device".  This was odd as I've been using that
> NFS-mounted root (and thus "/dev") directory since October 2012 and it
> had a fully-populated set of device nodes.

can you post the boot messages for drmkms?  it's really important
for wsdisplay0 to attach at drmkms.

> Rebooting with my default (UMS drm) kernel produced a working display and
> just to be sure, I re-ran "MAKEDEV all" in my "/dev" directory.  Looking
> at the resulting device nodes, I mostly noticed several disk devices which
> now had partitions above "h" (mostly the "xbd" devices for Xen).  Curiously,
> "/dev/console" was newly remade.
> 
> Rebooting with the drmkms-enabled kernel didn't panic but now produces
> a completely black display and unlike previous attempts there's no cursor
> and the keyboard is inoperative.  Holding the power switch is the only
> way to regain control of the machine.

this is what happens when you don't remember to take out vga and
pcdisplay @ isa.  can you make sure you did for this test?

> One thing I noticed is that UMS radeondrm driver reports the chip as
> "RV200", but both the UMS and KMS DRM drivers load "R100_cp.bin" instead
> of "R200_cp.bin".

it seems that often "RVx00" is lesser than "Rx00", this might just
be another case.  if both drivers agree, it's probably right.

> Unless it has been fixed, booting with serial console will not provide
> more information as the video output is completely disabled and driver
> will spin forever looking for an active output.  It will be a while
> before I can test that again.

serial console works for me for getting most things working.  it's
how i've been debugging drm stuff since the 1st gen drm code we had
in sys/dev/drm, and besides occasional failures it has been working
for me all this time.


.mrg.