Subject: port-mac/3147: interference of address and protection bits in pte
To: None <gnats-bugs@gnats.netbsd.org>
From: Walter Ruetten <walter@ghpc8.ihf.rwth-aachen.de>
List: netbsd-bugs
Date: 01/27/1997 07:13:50
>Number:         3147
>Category:       port-mac
>Synopsis:       video address not ending in 0x000 interferes with protection bits in pte
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jan 26 22:20:01 1997
>Last-Modified:
>Originator:     Walter Ruetten
>Organization:
	
>Release:        1.2
>Environment:
System: NetBSD islington.ihf.rwth-aachen.de 1.2B NetBSD 1.2B (ISLINGTON) #22: Mon Jan 20 20:03:20 MET 1997 walter@islington.ihf.rwth-aachen.de:/usr/src/sys/arch/mac68k/compile/ISLINGTON mac68k
        nubus graphic card: ColorServer II Lapis-15, CS II-15L,
        640x873 pixel full page display, 1 - 8 bit gray scale

>Description:
	
  GENERIC and self compiled kernels ( current from ~Dec 18, 1996)
  would hang after switchover to mapped mode when the
  Lapis ColorServer II graphic card was the primary display card.
  Serial console or internal video as primary display did work.

  Explanation:
  The start address of the Lapis video card was (correctly) reported
  as 0xfcc00004 by the Booter. This address (mac68k_vidphys) gets
  or-ed with the page protection bits (PG_RW, PG_CI, PG_V)
  in mac68k/pmap_bootstrap.c:395 to form the protopte.
  The last address digit (4) of mac68k_vidphys is lateron incorrectly 
  interpreted as PG_RO, marking the video memory as read-only.
  The next write to the video memory causes the system to crash
  without further notice (no exception handler set up at this time?).
    
>How-To-Repeat:
	
  Use any nubus graphic card with a video memory start address
  _not_ having the lowest three digits zero as primary display when
  booting NetBSD (Lapis ColorServer II Lapis-15 will do the job,
  hopefully there are not many of this kind around).

>Fix:
	
  - patch to pmap_bootstrap.c is given below.
  - if you are paranoid, the same problems can occur with
      IOBase  (mac68k/pmap_bootstrap.c:378) and
      ROMBase (mac68k/pmap_bootstrap.c:386)
    Do they ever start on strange boundaries?


*** pmap_bootstrap.c.orig	Tue Oct 15 13:38:40 1996
--- pmap_bootstrap.c	Tue Jan 21 20:21:24 1997
***************
*** 392,398 ****
  	if (vidlen) {
  		pte = PA2VA(vidpa, u_int *);
  		epte = pte + VIDMAPSIZE;
! 		protopte = mac68k_vidphys | PG_RW | PG_V | PG_CI;
  		while (pte < epte) {
  			*pte++ = protopte;
  			protopte += NBPG;
--- 392,398 ----
  	if (vidlen) {
  		pte = PA2VA(vidpa, u_int *);
  		epte = pte + VIDMAPSIZE;
! 		protopte = (mac68k_vidphys & ~PGOFSET) | PG_RW | PG_V | PG_CI;
  		while (pte < epte) {
  			*pte++ = protopte;
  			protopte += NBPG;
>Audit-Trail:
>Unformatted: