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: