kern/49709: radeondrmkms panic if "/dev/" is on NFS root

[jdbaker%mylinuxisp.com@localhost]

>Number:         49709
>Category:       kern
>Synopsis:       radeondrmkms panic if "/dev/" is on NFS root
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Mar 02 00:10:01 +0000 2015
>Originator:     John D. Baker
>Release:        NetBSD/i386-7.99.5, NetBSD/amd64-7.99.5
>Organization:
>Environment:
NetBSD slab 7.99.5 NetBSD 7.99.5 (SLAB_KMS) #7: Sun Mar  1 14:17:39 CST 2015  sysop%skuld.technoskunk.fur@localhost:/d0/build/current/obj/i386/sys/arch/i386/compile/SLAB_KMS i386

>Description:
If a diskless client uses radeondrmkms, the kernel will panic during
radeondrmkms attachment if the NFS-resident "/dev" is used.

[...]
drm: initializing kernel modesetting (RV200 0x1002:0x4C58 0x1014:0x0518).
drm: register mmio base: 0xd0100000
drm: register mmio size: 65536
radeon0: info: GTT: 64M 0xE0000000 - 0xE3FFFFFF
radeon0: info: VRAM: 128M 0x00000000E8000000 - 0x00000000EFFFFFFF (64M used)
drm: Detected VRAM RAM=80M, BAR=128M
drm: RAM width 128bits DDR
Zone  kernel: Available graphics memory: 801196 kiB
drm: radeon: 64M of VRAM memory ready
drm: radeon: 64M of GTT memory ready.
radeon0: info: WB disabled
radeon0: info: fence driver on ring 0 use gpu addr 0x00000000e0000000 and cpu addr 0x0xdb4f0000
drm: Supports vblank timestamp caching Rev 2 (21.10.2013).
drm: Driver supports precise vblank timestamp query.
radeon0: interrupting at irq 9 (radeon)
drm: radeon: irq initialized.
drm: Loading R100 microcode
panic: cnopen: no console device
fatal breakpoiknt trap in supervisor mode
trap type 1 code 0 eip c02516b4 cs 8 eflags 246 cr2 bba5ae24 ilevel 0 esp db539ce0
curlwp 0xc37d3d20 pid 2 lid 1 lowest kstack 0xdb5372c0
Stopped in pid 2.1 (init) at    netbsd:breakpoint+0x4:  popl    %ebp
db{0}> bt
breakpoint at netbsd:breakpoint+0x4
vpanic at netbsd:vpanic+0x127
panic at netbsd:panic+0x18
cnopen at at netbsd:cnopen+0x112
cdev_open at netbsd:cdev_open+0xea
spec_open at netbsd:spec_open+0x20e
VOP_OPEN at netbsd:VOP_OPEN+0x58
vn_open at netbsd:vn_open+0x21b
do_open at netbsd:do_open+0xd0
do_sys_openat at netbsd:do_sys_openat+0x75
sys_open at netbsd:sys_open+0x2c
syscall() at netbsd:syscall+0x82
--- syscall (number 5) ---
bba77b07:
db{0}> sh reg
ds          c06f0010    extent_insert_and_optimize.isra.0+0x70
es          10
fs          30
gs          10
edi         db539cfc
esi         c097335b    ostype+0x144be
ebp         db539cbc
ebx         104
edx         1
ecx         0
eax         1
eip         c02516b4
cs          8
eflags      246
esp         db539cbc
ss          10
netbsd:breakpoint+0x4:  popl     %ebp
db{0}>


Also observed on an HP ProLiant DL380 G5 (amd64).  The HP also panicked
in this fashion with "/dev" on local disk.  Output of 'uname -a'
and kernel message excerpt to follow in email addenda.

>How-To-Repeat:
Boot an i386 (amd64) system which uses radeondrmkms as a diskless client
with a fully-populated "/dev" directory on the NFS root.

Observe panic and claim of no console device.
>Fix:
Workaround:  use serial console
Workaround:  delete "/dev/console" from client root on server causing
"/dev" to be populated on boot-time tmpfs.