rapatel@porthos.rutgers.edu ( Rakesh Patel) (04/13/88)
I had (and still have) a problem getting the X11R2 server to run
properly on a Sun 4/260C. It attempts to autoconfigure for the
appropriate board. Its find the cgtwo board, succefully opens it (this
is in server/ddx/sun/sunCG2C.c within sunCG2CProbe()), but fails in an
mmap call, returning the following message, then finds the bwtwo and
runs. However, since I am running with the color monitor, I never see
anything on the color monitor. Here is the error it returns:
Mapping cg2c.image: Invalid arguement
The arguements to the call (mmap()) seem to be fine (and they do work
on a 3/160C). Anyone have any ideas? We know the cgtwo board works
fine (we can run suntools, stringart, NeWS, etc.), so that does not
seem to be the problem.
Here is the few lines of relevant code. I have marked the ---> in
front of the line it fails at:
CG2Cfb.image = (union byteplane *)valloc (CG2C_IMAGELEN + CG2C_REGLEN + CG2C_MASKLEN + CG2C_CMAPLEN);
CG2Cfb.u_csr = (struct cg2c_reg *) ((char *)CG2Cfb.image + CG2C_IMAGELEN);
CG2Cfb.u_ppmask = (struct cg2c_ppmask *) ((char *)CG2Cfb.u_csr + CG2C_REGLEN);
CG2Cfb.u_cmap = (struct cg2c_cmap *) ((char *)CG2Cfb.u_ppmask + CG2C_MASKLEN);
if (CG2Cfb.image == (union byteplane *) NULL) {
ErrorF ("Could not allocate room for frame buffer.\n");
sunFbData[fbNum].probeStatus = probedAndFailed;
return FALSE;
}
--> if (mmap (CG2C_IMAGE(CG2Cfb), CG2C_IMAGELEN, PROT_READ | PROT_WRITE,
MAP_SHARED, fd, CG2C_IMAGEOFF) < 0) {
Error ("Mapping cg2c.image");
goto bad;
}
I noticed that it had different ways of allocating memory pages
depending on whether _MAP_NEW was defined or not. I tried defining
_MAP_NEW, but ran into the same problem. I was able to verify using
that code, that the pages of memory were correctly allocated (though
I still can't be sure that the valloc is working without checking the
return status. If it works on a 3/160 with a cgtwo board, I don't see
how this code can break on the 4/260. I doubt the valloc call could
fail (we have 32 Megs in the machine). The only thing I can think of
is possibly a byte-alignment/word-boundary problem?
I don't see how something that works on other 4/260Cs could not work
on ours.
Rakesh Patel.