From frank@exit.com  Mon Feb  7 03:35:15 2005
Return-Path: <frank@exit.com>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id F260216A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Mon,  7 Feb 2005 03:35:15 +0000 (GMT)
Received: from tinker.exit.com (tinker.exit.com [206.223.0.1])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 8F8B943D2D
	for <FreeBSD-gnats-submit@freebsd.org>; Mon,  7 Feb 2005 03:35:13 +0000 (GMT)
	(envelope-from frank@exit.com)
Received: from realtime.exit.com (realtime [206.223.0.5])
	by tinker.exit.com (8.13.1/8.13.1) with ESMTP id j173ZAdM064059
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 6 Feb 2005 19:35:10 -0800 (PST)
	(envelope-from frank@exit.com)
Received: from realtime.exit.com (localhost [127.0.0.1])
	by realtime.exit.com (8.13.1/8.12.9) with ESMTP id j173ZA8l026538
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 6 Feb 2005 19:35:10 -0800 (PST)
	(envelope-from frank@realtime.exit.com)
Received: (from frank@localhost)
	by realtime.exit.com (8.13.1/8.13.1/Submit) id j173ZA2G026537;
	Sun, 6 Feb 2005 19:35:10 -0800 (PST)
	(envelope-from frank)
Message-Id: <200502070335.j173ZA2G026537@realtime.exit.com>
Date: Sun, 6 Feb 2005 19:35:10 -0800 (PST)
From: Frank Mayhar <frank@exit.com>
Reply-To: Frank Mayhar <frank@exit.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: Kernel panic "pmap_mapdev: Couldn't alloc kernel virtual memory" starting XFree86
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         77189
>Category:       i386
>Synopsis:       DRM: Kernel panic "pmap_mapdev: Couldn't alloc kernel virtual memory" starting XFree86
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    anholt
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Feb 07 03:40:16 GMT 2005
>Closed-Date:    Fri Jun 24 18:20:04 GMT 2005
>Last-Modified:  Fri Jun 24 18:20:04 GMT 2005
>Originator:     Frank Mayhar
>Release:        FreeBSD 4.11-STABLE i386
>Organization:
Exit Consulting
>Environment:
System: FreeBSD realtime.exit.com 4.11-STABLE FreeBSD 4.11-STABLE #4: Thu Jan 20 12:24:45 PST 2005 frank@realtime.exit.com:/usr/obj/usr/src/sys/REALTIME i386

Running XFree86 4.4.0 trying to do direct rendering with a Radeon 8500 128MB
display card.  Happens on 4-stable up to and including 4.11.

>Description:

I consistently hit a panic, "pmap_mapdev: Couldn't alloc kernel virtual
memory," when I try to start XFree86 4.4 with agp.ko and radeon.ko loaded.
I have a Radeon 8500 display card with 128MB of memory and I would like to
do direct rendering on it, but this bug makes doing so impossible.

The stack looks like:

#3  0xc01837d9 in poweroff_wait (junk=0xc0341340, howto=0xc5397300) at /usr/src/sys/kern/kern_shutdown.c:612
#4  0xc02dbbb2 in pmap_mapdev (pa=0xe0000000, size=0x8000000) at /usr/src/sys/i386/i386/pmap.c:3067
#5  0xc54d377a in radeon_ioremap (dev=0xc54c4000, map=0xc5397300) at @/dev/drm/drm_memory.h:243
#6  0xc54cf001 in radeon_addmap (kdev=0xc54c6d00, cmd=0xc0186415, data=0xf90d6ea4 "", flags=0x3, p=0xf8f6ad40)
    at @/dev/drm/drm_bufs.h:125
#7  0xc54d21ec in radeon_ioctl (kdev=0xc54c6d00, cmd=0xc0186415, data=0xf90d6ea4 "", flags=0x3, p=0xf8f6ad40)
    at @/dev/drm/drm_drv.h:1122
#8  0xc01bd8ee in spec_poll (ap=0xf90d6de0) at /usr/src/sys/miscfs/specfs/spec_vnops.c:323
#9  0xc01bd619 in spec_open (ap=0xf90d6de0) at /usr/src/sys/miscfs/specfs/spec_vnops.c:147
#10 0xc025c84d in default_pager_getpages (object=0xf90d6de0, m=0xc54fccc0, count=0x0, reqpage=0x18)
    at /usr/src/sys/vm/default_pager.c:100
#11 0xc01b9f57 in vn_ioctl (fp=0xc54fccc0, com=0xc0186415, data=0xf90d6ea4 "", p=0xf8f6ad40)
    at /usr/src/sys/kern/vfs_vnops.c:607
#12 0xc0192e52 in ioctl (p=0xf8f6ad40, uap=0xf90d6f80) at /usr/src/sys/kern/sys_generic.c:637
#13 0xc02dde79 in syscall2 (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f, tf_edi = 0x883f010, tf_esi = 0x7, 
      tf_ebp = 0xbfbff580, tf_isp = 0xf90d6fd4, tf_ebx = 0x0, tf_edx = 0x8000000, tf_ecx = 0x0, tf_eax = 0x36, 
      tf_trapno = 0xc, tf_err = 0x2, tf_eip = 0x4822568c, tf_cs = 0x1f, tf_eflags = 0x3293, tf_esp = 0xbfbff554, 
      tf_ss = 0x2f}) at /usr/src/sys/i386/i386/trap.c:1175

And the request like:

(kgdb) print *map
$5 = {
  offset = 0xe0000000, 
  size = 0x8000000, 
  type = _DRM_FRAME_BUFFER, 
  flags = 0, 
  handle = 0x0, 
  mtrr = 0x1, 
  iot = 0x0, 
  ioh = 0x0
}
(kgdb) print request
$6 = {
  offset = 0xe0000000, 
  size = 0x8000000, 
  type = _DRM_FRAME_BUFFER, 
  flags = 0, 
  handle = 0x0, 
  mtrr = 0x7
}

Looking at the code in question, it's clear that it's trying to allocate
the virtual space for the frame buffer, described in the logfile:

(--) RADEON(0): Chipset: "ATI Radeon 8500 QL (AGP)" (ChipID = 0x514c)
(--) RADEON(0): Linear framebuffer at 0xe0000000
(--) RADEON(0): VideoRAM: 131072 kByte (128 bit DDR SDRAM)   

And the allocation is failing.  It seems somewhat unfriendly to panic the
kernel in this case, especially since the calling code in radeon_ioremap()
knows how to handle a null return from pmap_mapdev() (it bumps a "fail"
counter and returns NULL).

It would also be really nice to know just why the allocation is failing,
since this machine has 2GB in it.  Do I need to increase the number of PTEs
somehow?

Just FYI, kernel_map looks like

(kgdb) print *kernel_map
$20 = {
  header = {
    prev = 0xe09d9ff0, 
    next = 0xc03a2330, 
    start = 0xbfeff000, 
    end = 0xffbff000, 
    avail_ssize = 0x0, 
    object = {
      vm_object = 0x0, 
      sub_map = 0x0
    }, 
    offset = 0x0, 
    eflags = 0x0, 
    protection = 0x0, 
    max_protection = 0x0, 
    inheritance = 0x0, 
    wired_count = 0x0, 
    lastr = 0x0
  }, 
  lock = {
    lk_interlock = {
      lock_data = 0x0
    }, 
    lk_flags = 0x1000000, 
    lk_sharecount = 0x0, 
    lk_waitcount = 0x0, 
    lk_exclusivecount = 0x0, 
    lk_prio = 0x4, 
    lk_wmesg = 0xc0326554 "thrd_sleep", 
    lk_timo = 0x0, 
    lk_lockholder = 0xffffffff
  }, 
  nentries = 0xc3, 
  size = 0x391ab000, 
  system_map = 0x1, 
  infork = 0x0, 
  hint = 0xe09da470, 
  timestamp = 0x49a, 
  first_free = 0xe09d9300, 
  pmap = 0xc03b2720
}

I'll have the dump lying around for a while, so if there's any more
information you would like, let me know.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-i386->anholt 
Responsible-Changed-By: anholt 
Responsible-Changed-When: Fri Feb 18 06:43:29 GMT 2005 
Responsible-Changed-Why:  
Grab this one.  The proper fix is to bus_space and bus_dma-ify the DRM, so we 
can have failing allocations, and to also not map the framebuffer in kernel 
unless necessary. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=77189 
State-Changed-From-To: open->closed 
State-Changed-By: anholt 
State-Changed-When: Fri Jun 24 18:18:26 GMT 2005 
State-Changed-Why:  
This is fixed in 5-stable by a DRM change to not map framebuffer in the kernel, 
since it's unnecessary.  I'm not supporting DRM on 4.x any more so I'm closing 
the PR.  The issue resurfaced in -current in a different code path, but 
kern/80718 is covering the issue and I've got a patch ready for testing. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=77189 
>Unformatted:
