NetBSD Problem Report #49833

From www@NetBSD.org  Fri Apr 10 02:40:51 2015
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id CD07BA6562
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 10 Apr 2015 02:40:50 +0000 (UTC)
Message-Id: <20150410024027.4A1A8A65B0@mollari.NetBSD.org>
Date: Fri, 10 Apr 2015 02:40:27 +0000 (UTC)
From: kosaki_ka@ybb.ne.jpta
Reply-To: kosaki_ka@ybb.ne.jpta
To: gnats-bugs@NetBSD.org
Subject: NetBSD-current (amd64/i386) reboot when start xinit on pc with HD6450
X-Send-Pr-Version: www-1.0

>Number:         49833
>Category:       kern
>Synopsis:       NetBSD-current (amd64/i386) reboot when start xinit on pc with HD6450
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    riastradh
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Apr 10 02:45:00 +0000 2015
>Closed-Date:    Thu Apr 23 08:26:03 +0000 2015
>Last-Modified:  Thu Apr 23 08:26:03 +0000 2015
>Originator:     Kotaro Kosaki
>Release:        NetBSD 7.99.9 (GENERIC)
>Organization:
>Environment:
NetBSD phnm1 7.99.9 NetBSD 7.99.9 (GENERIC) #0: Thu Apr  9 17:29:30 JST 2015  kosaki@phnm1:/udd4/amd64/obj/sys/arch/amd64/compile/GENERIC amd64
>Description:
NetBSD-current (amd64/i386)  on pc with HD6450

console login ok
when  start xinit reboot
size of Xorg.0.log is 0

Mother board is
dual Opteron socket 940
Supermicro H8DCE-HTE (1234567890)
chipset nForce Pro 2200/2060
with onboard Rage XL vga

Graphics board is HD6450

may be a rare case?
>How-To-Repeat:
console login and start xinit

>Fix:
use previous version 

src/sys/external/bsd/drm2/dist/drm/radeon/radeon_agp.c ver 1.2
src/sys/external/bsd/drm2/dist/drm/radeon/radeon_object.c ver 1.2
src/sys/external/bsd/drm2/dist/drm/ttm/ttm_bo.c ver 1.6

This solves  reboot problem. But I think my case is rare,because no one report this reboot problem.

>Release-Note:

>Audit-Trail:
From: kosaki_ka@ybb.ne.jp
To: "gnats-bugs@NetBSD.org" <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: port-amd64/49833
Date: Mon, 13 Apr 2015 19:45:47 +0900 (JST)

 =0A=0Atest on i1386 system =0A=0Awith=A0 files=A0 =0A=0Arc/sys/external/bsd=
 /drm2/dist/drm/radeon/radeon_agp.c ver 1.3=0Asrc/sys/external/bsd/drm2/dist=
 /drm/radeon/radeon_object.c ver 1.3=0Asrc/sys/external/bsd/drm2/dist/drm/tt=
 m/ttm_bo.c ver 1.9=0A=0Aconsole login ok=0Axinit =0Athen reboot=0A=0A=0A=0A=
 phnm2@/var/crash# crash -M netbsd.9.core=0ACrash version 7.99.9, image vers=
 ion=A0 2008, 2009, 201.=0AWARNING: versions differ, you may not be able to =
 examine this image.=0ASystem panicked: kernel diagnostic assertion "(bo->me=
 m.bus.base & (PAGE_SIZE - 1)) =3D=3D 0" failed: file "/mnt2/usr/src/sys/ext=
 ernal/bsd/drm2/dist/drm/ttm/ttm_bo.c", line 1618 bo bus base addr not page-=
 aligned: c071464e=0ABacktrace from time of crash is available.=0A=0Acrash> =
 bt=0A_KERNEL_OPT_NARCNET(0,104,c0718116,8,c0de46fd,2,104,c0e83e7c,dd731bc4,=
 dd731ba8) at 0=0A_end(104,0,c0e83e7c,dd731bc4,c5e8f0fc,c5e8f0fc,c451909c,dd=
 731bb8,c0b407fb,c0e83e7c) at dd7=0A31bc4=0Asnprintf(c0e83e7c,dd731bc4,dd731=
 be4,c09e6a00,c0e83e7c,c0dc39c9,c0e83e50,c0e83c60,652,c0714=0A64e) at snprin=
 tf+0x6=0Aar2413ReadCalDataset(c0e83e7c,c0dc39c9,c0e83e50,c0e83c60,652,c0714=
 64e,c5e8f0fc,c4518674,c4=0A51909c,dd731bfc) at ar2413ReadCalDataset+0x1af=
 =0Attm_bo_handle_move_mem(c5e8f0fc,0,c4518000,c5bf0c4c,dd731c40,c086baa9,c5=
 e8f0fc,5,c49f449c,=0Ac49f44a0) at ttm_bo_handle_move_mem+0x1a0=0Attm_bo_rel=
 ease(c5e8f0fc,5,c49f449c,c49f44a0,c4518000,dd731c2c,c01f0111,c49f44a0,dd731=
 c40,c=0A4518b60) at ttm_bo_release+0x15=0Aradeon_pm_set_clocks(c45190a4,dd7=
 31c68,c01f087d,c4bb210c,c45190a4,c4c8100c,c4bb2284,c0b97e=0A40,dd731c7c,c01=
 f0c83) at radeon_pm_set_clocks+0x281=0Aradeon_pm_compute_clocks(c4518000,3,=
 c4c8100c,dd731d98,c02e9174,c4c8100c,c4c81038,c4c8d3ac,=0Add731cf0,0) at rad=
 eon_pm_compute_clocks+0x16e=0Aatombios_crtc_prepare(c4c8100c,c4c81038,c4c8d=
 3ac,dd731cf0,0,c4ba4b40,c4c8100c,c4c81038,0,0=0A) at atombios_crtc_prepare+=
 0x3d=0Adrm_crtc_helper_set_mode(c4c8100c,c4c81038,0,0,c4c8ae7c,dd731ddc,c08=
 51280,c02e3324,c4bb224=0A0,b) at drm_crtc_helper_set_mode+0x294=0Aradeon_co=
 nnector_set_property(c02e3324,c4bb2240,b,2,0,0,c4c7b74c,c4bb210c,dd731e18,c=
 02e70c=0A2) at radeon_connector_set_property+0x3e=0Aradeon_connector_set_pr=
 operty(c4c6f00c,c4c7b744,2,0,c4bb2240,c4c7b74c,3,2,0,c4c6f020) at r=0Aadeon=
 _connector_set_property+0x1c0=0Adrm_mode_obj_set_property_ioctl(c4bb210c,dd=
 731e2c,c601ff38,2,0,b,18,c0c0c0c0,dd731e6c,c02e=0Ab645) at drm_mode_obj_set=
 _property_ioctl+0x153=0Adrm_mode_connector_property_set_ioctl(c4bb210c,dd73=
 1eac,c601ff38,c4ba3848,11d,c5fac94c,dd7=0A31f68,c01064ab,c5fb9940,dd731f38)=
  at drm_mode_connector_property_set_ioctl+0x40=0Adrm_ioctl(c5fb9940,c01064a=
 b,dd731eac,1,0,0,c5fea460,0,10,0) at drm_ioctl+0x11e=0Asys_ioctl(c5036540,d=
 d731f68,dd731f60,2,bb390000,c1074018,dd731f68,36,0,0) at sys_ioctl+0x2=0A28=
 =0Asyscall() at syscall+0x11a=0A--- syscall (number 54) ---=0Abb771f47:=0A

From: kosaki_ka@ybb.ne.jp
To: "gnats-bugs@NetBSD.org" <gnats-bugs@NetBSD.org>
Cc: "reinoud@NetBSD.org" <reinoud@NetBSD.org>
Subject: Re: port-amd64/49833 ( drmkms  ttm_bo.c  HD6450 reboot ) 
Date: Thu, 16 Apr 2015 13:21:24 +0900 (JST)

 --364736203-1468043257-1429158084=:11952
 Content-Type: text/plain; charset=iso-8859-1
 Content-Transfer-Encoding: quoted-printable

 With recent sources, drmkms kernel with HD6450 kernel reboot.=0A=0A=0ASyste=
 m panicked: kernel diagnostic assertion=0A"(bo->mem.bus.base & (PAGE_SIZE -=
  1)) =3D=3D 0" failed:=0Afile "/mnt2/usr/src/sys/external/bsd/drm2/dist/drm=
 /ttm/ttm_bo.c", =0Aline 1618 bo bus base addr not page-aligned: c0714bfe=0A=
 =0A=0AThat kernel with  new ttm_bo.c=A0 causes reboot=A0 is reported in=0A=
 =0Ahttp://mail-index.netbsd.org/tech-kern/2015/04/14/msg018612.html=0A=0A=
 =0ASo ,I=A0 think port-amd64/49833 may be closed .=0A
 --364736203-1468043257-1429158084=:11952
 Content-Type: text/html; charset=iso-8859-1
 Content-Transfer-Encoding: quoted-printable

 <html><body><div style=3D"color:; background-color:; font-family:MS PGothic=
 , sans-serif;font-size:12pt"><div>With recent sources, drmkms kernel with H=
 D6450 kernel reboot.<br></div><div><br></div><div>System panicked: kernel d=
 iagnostic assertion<br>"(bo-&gt;mem.bus.base &amp; (PAGE_SIZE - 1)) =3D=3D =
 0" failed:<br>file "/mnt2/usr/src/sys/external/bsd/drm2/dist/drm/ttm/ttm_bo=
 .c", <br>line 1618 bo bus base addr not page-aligned: c0714bfe<br><br></div=
 ><div>That kernel with  new ttm_bo.c&nbsp; causes reboot&nbsp; is reported =
 in</div><div><br></div><div>http://mail-index.netbsd.org/tech-kern/2015/04/=
 14/msg018612.html</div><div><br></div><div><br></div><div>So ,I&nbsp; think=
  port-amd64/49833 may be closed .</div></div></body></html>
 --364736203-1468043257-1429158084=:11952--

From: kosaki_ka@yahoo.co.jp
To: "gnats-bugs@NetBSD.org" <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: port-amd64/49833 ( drmkms ttm_bo.c HD6450 reboot )
Date: Thu, 16 Apr 2015 19:05:45 +0900 (JST)

 =0A=0A=A0Excuse me, please=A0 replace previous richtextmode=A0 post with th=
 e following =0A=0A----------------------------------------------------=0AWi=
 th recent sources, drmkms kernel with HD6450 kernel reboot.=0A=0A=0ASystem =
 panicked: kernel diagnostic assertion=0A"(bo->mem.bus.base & (PAGE_SIZE - 1=
 )) =3D=3D 0" failed:=0Afile "/mnt2/usr/src/sys/external/bsd/drm2/dist/drm/t=
 tm/ttm_bo.c", =0Aline 1618 bo bus base addr not page-aligned: c0714bfe=0A=
 =0A=0AThat kernel with=A0=A0new ttm_bo.c=A0 causes reboot=A0 is reported in=
 =0A=0Ahttp://mail-index.netbsd.org/tech-kern/2015/04/14/msg018612.html=0A=
 =0A=0ASo ,I=A0 think port-amd64/49833 may be closed .

From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: port-amd64-maintainer@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org
Subject: re: port-amd64/49833: NetBSD-current (amd64/i386) reboot when start xinit on pc with HD6450
Date: Sun, 19 Apr 2015 07:32:52 +1000

 this seems to be specific to HD6450 (at least, it doesn't happen
 on my hd5450, hd 4xxx, r300 systems.)  however, it does happen on
 the new 6450 i have.

 the problem seems to occur early in boot.  i patched
 radeon_bo_create() to look for the misaligned base/offset and it
 triggers before init starts:

 radeon0: warning: created bo 0xfffffe80bec46810 with base ffff80000573f760 offset fffffe8046364c38
 panic: kernel diagnostic assertion "(bo->tbo.mem.bus.base & (PAGE_SIZE - 1)) == 0" failed: file "/usr/src4/sys/external/bsd/drm2/dist/drm/radeon/radeon_object.c", line 205 bo bus base addr not page-aligned: ffff80000573f760
 cpu1: Begin traceback...
 vpanic() at netbsd:vpanic+0x13c
 kern_assert() at netbsd:kern_assert+0x4f
 radeon_bo_create() at netbsd:radeon_bo_create+0x23b
 radeon_ttm_init() at netbsd:radeon_ttm_init+0x171
 evergreen_init() at netbsd:evergreen_init+0xd9
 radeon_device_init() at netbsd:radeon_device_init+0x4d0
 radeon_driver_load_kms() at netbsd:radeon_driver_load_kms+0x6d
 drm_dev_register() at netbsd:drm_dev_register+0x87
 drm_pci_attach() at netbsd:drm_pci_attach+0x2d5
 radeon_attach_real() at netbsd:radeon_attach_real+0x68
 config_mountroot_thread() at netbsd:config_mountroot_thread+0x2c

 the "warning" is also a new message i added, so i could track
 what bo had what initial base/offset, and see where corruption
 is introduced, but i did not expect it to occur so early.


 more investigation required, but i wanted to share this info.


 .mrg.

From: matthew green <mrg@eterna.com.au>
To: port-amd64-maintainer@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org, gnats-bugs@NetBSD.org, riastradh@netbsd.org
Cc: 
Subject: re: port-amd64/49833: NetBSD-current (amd64/i386) reboot when start xinit on pc with HD6450
Date: Sun, 19 Apr 2015 10:48:48 +1000

 this seems to fix the problem for me.  i *think* we're not supposed
 to be looking at these values, and the simplest way i can see to
 ensure this is to initialise something - the something we check
 later when the assert is triggered.

 with this in place, i'm able to run X and basic GL apps.  bzflag
 dumps core, but that might be bzflag itself.  glxgears without vsync
 enabled runs fairly slowly -- only about 200fps (my radeonhd 5450
 gets about 2000fps), so there might be some problems still.

 Taylor?  comments?


 .mrg.


 Index: dist/drm/ttm/ttm_bo.c
 ===================================================================
 RCS file: /cvsroot/src/sys/external/bsd/drm2/dist/drm/ttm/ttm_bo.c,v
 retrieving revision 1.9
 diff -p -u -r1.9 ttm_bo.c
 --- dist/drm/ttm/ttm_bo.c	10 Apr 2015 17:28:42 -0000	1.9
 +++ dist/drm/ttm/ttm_bo.c	19 Apr 2015 00:43:39 -0000
 @@ -1018,6 +1018,9 @@ static int ttm_bo_move_buffer(struct ttm
  	spin_unlock(&bdev->fence_lock);
  	if (ret)
  		return ret;
 +#ifdef __NetBSD__
 +	mem.bus.is_iomem = false;
 +#endif
  	mem.num_pages = bo->num_pages;
  	mem.size = mem.num_pages << PAGE_SHIFT;
  	mem.page_alignment = bo->mem.page_alignment;

Responsible-Changed-From-To: port-amd64-maintainer->riastradh
Responsible-Changed-By: riastradh@NetBSD.org
Responsible-Changed-When: Mon, 20 Apr 2015 12:24:08 +0000
Responsible-Changed-Why:
mine


From: Taylor R Campbell <riastradh@NetBSD.org>
To: matthew green <mrg@eterna.com.au>
Cc: port-amd64-maintainer@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, gnats-bugs@NetBSD.org
Subject: Re: port-amd64/49833: NetBSD-current (amd64/i386) reboot when start xinit on pc with HD6450
Date: Mon, 20 Apr 2015 12:24:54 +0000

    Date: Sun, 19 Apr 2015 10:48:48 +1000
    from: matthew green <mrg@eterna.com.au>

    Taylor?  comments?

    --- dist/drm/ttm/ttm_bo.c	10 Apr 2015 17:28:42 -0000	1.9
    +++ dist/drm/ttm/ttm_bo.c	19 Apr 2015 00:43:39 -0000
    @@ -1018,6 +1018,9 @@ static int ttm_bo_move_buffer(struct ttm
            spin_unlock(&bdev->fence_lock);
            if (ret)
                    return ret;
    +#ifdef __NetBSD__
    +	mem.bus.is_iomem = false;
    +#endif

 No need for #ifdef __NetBSD__; otherwise LGTM.  I think this is right
 and certainly it can't hurt.  I'm asking upstream for confirmation.

From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/49833 CVS commit: src/sys/external/bsd/drm2/dist/drm/ttm
Date: Mon, 20 Apr 2015 20:15:22 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Mon Apr 20 20:15:22 UTC 2015

 Modified Files:
 	src/sys/external/bsd/drm2/dist/drm/ttm: ttm_bo.c

 Log Message:
 Make sure mem.bus.is_iomem is initialized.  PR 49833


 To generate a diff of this commit:
 cvs rdiff -u -r1.9 -r1.10 src/sys/external/bsd/drm2/dist/drm/ttm/ttm_bo.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Soren Jacobsen" <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/49833 CVS commit: [netbsd-7] src/sys
Date: Thu, 23 Apr 2015 07:31:18 +0000

 Module Name:	src
 Committed By:	snj
 Date:		Thu Apr 23 07:31:17 UTC 2015

 Modified Files:
 	src/sys/arch/x86/include [netbsd-7]: pmap.h
 	src/sys/arch/x86/x86 [netbsd-7]: pmap.c
 	src/sys/dev/pci [netbsd-7]: agp_amd64.c agp_i810.c
 	src/sys/external/bsd/drm2/dist/drm/i915 [netbsd-7]: i915_dma.c
 	    i915_gem.c
 	src/sys/external/bsd/drm2/dist/drm/nouveau [netbsd-7]: nouveau_agp.c
 	    nouveau_ttm.c
 	src/sys/external/bsd/drm2/dist/drm/radeon [netbsd-7]: atombios_crtc.c
 	    radeon_agp.c radeon_display.c radeon_legacy_crtc.c radeon_object.c
 	    radeon_ttm.c
 	src/sys/external/bsd/drm2/dist/drm/ttm [netbsd-7]: ttm_bo.c
 	    ttm_bo_util.c
 	src/sys/external/bsd/drm2/i915drm [netbsd-7]: intelfb.c
 	src/sys/external/bsd/drm2/include/drm [netbsd-7]: drm_wait_netbsd.h
 	src/sys/external/bsd/drm2/include/linux [netbsd-7]: mm.h pci.h
 	src/sys/external/bsd/drm2/nouveau [netbsd-7]: nouveaufb.c
 	src/sys/external/bsd/drm2/radeon [netbsd-7]: radeon_pci.c
 	src/sys/uvm [netbsd-7]: uvm_init.c

 Log Message:
 Pull up following revision(s) (requested by mrg in ticket #718):
 	sys/arch/x86/include/pmap.h: revision 1.56
 	sys/arch/x86/x86/pmap.c: revision 1.188
 	sys/dev/pci/agp_amd64.c: revision 1.8
 	sys/dev/pci/agp_i810.c: revision 1.118
 	sys/external/bsd/drm2/dist/drm/i915/i915_dma.c: revision 1.16
 	sys/external/bsd/drm2/dist/drm/i915/i915_gem.c: revision 1.29
 	sys/external/bsd/drm2/dist/drm/nouveau/nouveau_agp.c: revision 1.3
 	sys/external/bsd/drm2/dist/drm/nouveau/nouveau_ttm.c: revision 1.4
 	sys/external/bsd/drm2/dist/drm/radeon/atombios_crtc.c: revision 1.3
 	sys/external/bsd/drm2/dist/drm/radeon/radeon_agp.c: revision 1.3
 	sys/external/bsd/drm2/dist/drm/radeon/radeon_display.c: revision 1.3
 	sys/external/bsd/drm2/dist/drm/radeon/radeon_legacy_crtc.c: revision 1.2
 	sys/external/bsd/drm2/dist/drm/radeon/radeon_object.c: revision 1.3
 	sys/external/bsd/drm2/dist/drm/radeon/radeon_ttm.c: revision 1.7
 	sys/external/bsd/drm2/dist/drm/ttm/ttm_bo.c: revisions 1.7-1.10
 	sys/external/bsd/drm2/dist/drm/ttm/ttm_bo_util.c: revision 1.5
 	sys/external/bsd/drm2/i915drm/intelfb.c: revision 1.13
 	sys/external/bsd/drm2/include/drm/drm_wait_netbsd.h: revisions 1.12, 1.13
 	sys/external/bsd/drm2/include/linux/mm.h: revision 1.5
 	sys/external/bsd/drm2/include/linux/pci.h: revisions 1.16, 1.17
 	sys/external/bsd/drm2/nouveau/nouveaufb.c: revision 1.2
 	sys/external/bsd/drm2/radeon/radeon_pci.c: revisions 1.8, 1.9
 	sys/uvm/uvm_init.c: revision 1.46
 Hack against the blank console problem:
 Leave the CLUT alone on ancient cards. At least this leaves us with a
 semi working console (red and blue are flipped). Leave an example of what
 seems to be happening but disable it because colors are better than 444 bit
 greyscale.
 --
 Initialize P->V tracking for unmanaged device pages in uvm_init.

 Conditional on __HAVE_PMAP_PV_TRACK until we add it to all pmaps.

 MI part of pmap_pv(9) change proposed on tech-kern:

 https://mail-index.netbsd.org/tech-kern/2015/03/26/msg018561.html
 --
 Implement pmap_pv(9) for x86 for P->V tracking of unmanaged pages.

 Proposed on tech-kern with no objections:

 https://mail-index.netbsd.org/tech-kern/2015/03/26/msg018561.html
 --
 Use pmap_pv(9) to remove mappings of Intel graphics aperture pages.

 Proposed on tech-kern with no objections:

 https://mail-index.netbsd.org/tech-kern/2015/03/26/msg018561.html

 Further background at:

 https://mail-index.netbsd.org/tech-kern/2014/07/23/msg017392.html
 --
 Use pmap_pv(9) to remove mappings of device pages in TTM.

 Adapt nouveau and radeon to do pmap_pv_track for their device pages.

 Proposed on tech-kern with no objections:

 https://mail-index.netbsd.org/tech-kern/2015/03/26/msg018561.html

 Further background at:

 https://mail-index.netbsd.org/tech-kern/2014/07/23/msg017392.html
 --
 Fix error branches in agp_amd64.c.

 - agp_generic_detach always.
 - Free asc if it was allocated.  (Found by Brainy, noted by maxv@.)
 - Free the GATT if it was allocated.
 --
 pmf_device_register returns false on failure, not true
 --
 In DRM_SPIN_WAIT_ON, don't stop after waiting only one tick.

 Continue the loop to recheck the condition and count the whole
 duration.
 --
 Don't use the video BIOS memory as an i915 flush page!
 --
 Don't let anyone else allocate the video BIOS either.
 --
 Missed a zero: it's 0x100000, not 0x10000.
 --
 Don't reserve if atomic -- caller must have pre-pinned the buffer.
 --
 Don't reserve if atomic -- caller must have pre-pinned the buffer.
 --
 almost add radeondrmkms suspend/resume support.  it unfortunately doesn't work.
 --
 Need the page's uvm object lock to do pmap_page_protect.
 --
 Use KASSERTMSG to show bad base/offset.
 --
 KASSERT about page-alignment on initialization too.
 --
 Don't break when hardclock_ticks wraps around.

 Since we now only count time spent in wait, rather than determining
 the end time and checking whether we've passed it, timeouts might be
 marginally longer in effect.  Unlikely to be an issue.
 --
 Remove broken drm2 vm_mmap stub.  Can't possibly have ever worked.
 --
 apply some of the additional changes from Arto Huusko in PR#49645:
 - call pmf_device_deregister on detach.

 i've kept the "resume = true" for radeon_resume_kms() call as it
 seems to work for me (indeed, code inspection shows it is unused
 on netbsd :-)

 my old nforce4 box that can resume old drm (or could, last i tried
 several years ago) while X and GL apps were running, can at least
 survive a resume if X hasn't started.  my one attempt so far with
 X exited, but having run, did not work.
 --
 First attempt to make ttm_buffer_object_transfer less bogus.
 --
 Make sure mem.bus.is_iomem is initialized.  PR 49833


 To generate a diff of this commit:
 cvs rdiff -u -r1.55 -r1.55.4.1 src/sys/arch/x86/include/pmap.h
 cvs rdiff -u -r1.183.2.1 -r1.183.2.2 src/sys/arch/x86/x86/pmap.c
 cvs rdiff -u -r1.7 -r1.7.14.1 src/sys/dev/pci/agp_amd64.c
 cvs rdiff -u -r1.112.2.2 -r1.112.2.3 src/sys/dev/pci/agp_i810.c
 cvs rdiff -u -r1.10.2.3 -r1.10.2.4 \
     src/sys/external/bsd/drm2/dist/drm/i915/i915_dma.c
 cvs rdiff -u -r1.14.2.7 -r1.14.2.8 \
     src/sys/external/bsd/drm2/dist/drm/i915/i915_gem.c
 cvs rdiff -u -r1.2 -r1.2.4.1 \
     src/sys/external/bsd/drm2/dist/drm/nouveau/nouveau_agp.c
 cvs rdiff -u -r1.2.4.1 -r1.2.4.2 \
     src/sys/external/bsd/drm2/dist/drm/nouveau/nouveau_ttm.c
 cvs rdiff -u -r1.2 -r1.2.4.1 \
     src/sys/external/bsd/drm2/dist/drm/radeon/atombios_crtc.c \
     src/sys/external/bsd/drm2/dist/drm/radeon/radeon_agp.c \
     src/sys/external/bsd/drm2/dist/drm/radeon/radeon_display.c \
     src/sys/external/bsd/drm2/dist/drm/radeon/radeon_object.c
 cvs rdiff -u -r1.1.1.1 -r1.1.1.1.4.1 \
     src/sys/external/bsd/drm2/dist/drm/radeon/radeon_legacy_crtc.c
 cvs rdiff -u -r1.5.4.1 -r1.5.4.2 \
     src/sys/external/bsd/drm2/dist/drm/radeon/radeon_ttm.c
 cvs rdiff -u -r1.4.2.1 -r1.4.2.2 \
     src/sys/external/bsd/drm2/dist/drm/ttm/ttm_bo.c
 cvs rdiff -u -r1.4 -r1.4.2.1 \
     src/sys/external/bsd/drm2/dist/drm/ttm/ttm_bo_util.c
 cvs rdiff -u -r1.9.4.2 -r1.9.4.3 src/sys/external/bsd/drm2/i915drm/intelfb.c
 cvs rdiff -u -r1.4.2.3 -r1.4.2.4 \
     src/sys/external/bsd/drm2/include/drm/drm_wait_netbsd.h
 cvs rdiff -u -r1.3.2.1 -r1.3.2.2 src/sys/external/bsd/drm2/include/linux/mm.h
 cvs rdiff -u -r1.7.2.5 -r1.7.2.6 \
     src/sys/external/bsd/drm2/include/linux/pci.h
 cvs rdiff -u -r1.1.2.2 -r1.1.2.3 \
     src/sys/external/bsd/drm2/nouveau/nouveaufb.c
 cvs rdiff -u -r1.4.4.1 -r1.4.4.2 \
     src/sys/external/bsd/drm2/radeon/radeon_pci.c
 cvs rdiff -u -r1.45 -r1.45.12.1 src/sys/uvm/uvm_init.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->closed
State-Changed-By: mrg@NetBSD.org
State-Changed-When: Thu, 23 Apr 2015 08:26:03 +0000
State-Changed-Why:
fixed and pulled up.


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.