mike@ai.etl.army.mil (Mike McDonnell) (01/07/90)
I cannot get the Xsun server to run on my Sun 3/260 with a cgtwo graphics
board. here is what I get when I try to run xinit as root.
First a script with only /dev/cgtwo0 defined.
The ################ signs are before command lines:
================================================================
Script started on Sat Jan 6 15:59:45 1990
################
root:/usr/local/bin/X> ./xinit
Getting interface configuration: Operation not supported on socket
sunOpenFrameBuffer: Inappropriate ioctl for device
Fatal server bug!
no screens found
XIO: fatal IO error 32 (Broken pipe) on X server "(null)"
after 0 requests (0 known processed) with 0 events remaining.
The connection was probably broken by a server shutdown or KillClient.
################
root:/usr/local/bin/X> ./xinit -- -dev /dev/cgtwo0
Getting interface configuration: Operation not supported on socket
sunOpenFrameBuffer: Inappropriate ioctl for device
Fatal server bug!
no screens found
XIO: fatal IO error 32 (Broken pipe) on X server "(null)"
after 0 requests (0 known processed) with 0 events remaining.
The connection was probably broken by a server shutdown or KillClient.
################
root:/usr/local/bin/X> exit
script done on Sat Jan 6 16:00:34 1990
================================================================
now a script with /dev/fb defined.
Note that /dev/fb seems to generate a lot of fruitless ioctl() calls:
================================================================
Script started on Sat Jan 6 16:04:12 1990
################
root:/usr/local/bin/X> xinit
Getting interface configuration: Operation not supported on socket
sunOpenFrameBuffer: Inappropriate ioctl for device
sunOpenFrameBuffer: Inappropriate ioctl for device
sunOpenFrameBuffer: Inappropriate ioctl for device
sunOpenFrameBuffer: Inappropriate ioctl for device
sunOpenFrameBuffer: Inappropriate ioctl for device
Fatal server bug!
no screens found
XIO: fatal IO error 32 (Broken pipe) on X server "(null)"
after 0 requests (0 known processed) with 0 events remaining.
The connection was probably broken by a server shutdown or KillClient.
################
root:/usr/local/bin/X> exit
script done on Sat Jan 6 16:04:21 1990
================================================================
These problems seem to be caused by failure of an FBIOGATTR ioctl() call.
Besides the above problems, I get a similar failure when I try to find out
if my cgtwo0 or fb device is good by making a FBIOGATTR ioctl() call myself
[I used variations of the program 'constype']. Could there be a
hardware problem?
Some facts:
/dev is mode 777
/dev/cgtwo and /dev/fb are both mode 666
A cgtwo device is found at boot time, so I know it's in there somewhere.
No /dev/bw* devices are defined.
I am not running on top of Sun windows, so macro SUN_WINDOWS is undefined.
The release 3 server worked fine.
I compiled with version 1.36.1 of gcc.
--
Mike McDonnell at the U.S. Army Engineer Topographic Laboratories, Bldg. 2592
Fort Belvoir, VA 22060-5546 TEL:(202)355-2716 NET: mike@etl.army.milrws@EXPO.LCS.MIT.EDU (Bob Scheifler) (01/07/90)
I compiled with version 1.36.1 of gcc. Are you sure you've run "fixincludes" from the gcc distribution? You need to in order to get ioctl()s to compile correctly in R4 (this wasn't the case the way people normally built R3). If you haven't, you'll have to fun fixincludes and then rebuild any files with ioctl calls in them.
keith@EXPO.LCS.MIT.EDU (Keith Packard) (01/07/90)
> No /dev/bw* devices are defined. > I am not running on top of Sun windows, so macro SUN_WINDOWS is undefined. > The release 3 server worked fine. > I compiled with version 1.36.1 of gcc. Every ioctl call in your distribution is not working because the person who installed gcc neglected to run fixincludes on the machine you're building R4 with. Run 'fixincludes' from the gcc distribution and rebuild the X distribution. You could search the entire X tree for users of ioctl and rebuild those files, but it is sufficient just to 'make clean; make' from the top level (if a bit slower). Keith Packard MIT X Consortium
casey@gauss.llnl.gov (Casey Leedom) (01/07/90)
| From: keith@EXPO.LCS.MIT.EDU (Keith Packard) | | Every ioctl call in your distribution is not working because the person | who installed gcc neglected to run fixincludes on the machine you're | building R4 with. Doing that is annoying. Some of us strive to avoid modifying the vendor's stock software. There are many reasons for this: 1. Unbridled hacking obviously leaves one with a totally worthless system. Nothing works in any standard way any more. That said, let's assume we're merely talking about moderate modifications to vendor software systems in the following comments. 2. Whenever a new version of the vendor software comes out one has to hunt up all the special hacks that were made against the last version of the vendor software, checking which ones still need to be made, etc. 3. Often, hacks on the vendor software will have unexpected side- effects on other vendor software or even user software. Quite reasonably vendors don't have a lot of sympathy when people get themselves into trouble this way. All in all, it's obvious that one wants to keep the number of hacks against vendor stock software to an absolute minimum. (This, by the way, is why a lot of people prefer to install X under /usr/local/... rather than the current defaults. If you're going to insist on defaults and leave those defaults accidentally hard coded in various places from time to time, at least use a more reasonable default like /usr/local/... or even just test installing it under /usr/local even once ...) So my question: why did you set up the server so we can't use -traditional with gcc?????? I really don't want to screw around with my vendor software by running gcc's fixincludes script. Casey
casey@gauss.llnl.gov (Casey Leedom) (01/07/90)
I've been told that GCC's fixincludes script doesn't edit the vendor include files. It creates a shadow symbolic link tree containing a few edited files. GCC searches for include files in the shadow tree first. Thanks to Tad Guy (tadguy@cs.odu.edu) for pointing this out to me. I will go and run GCC's fixincludes forthwith. Note that I continue to stand by my observations and feeling regarding modifying vendor stock software. Casey
csu@alembic.acs.com (Dave Mack) (01/13/90)
In article <9001062237.AA14264@expo.lcs.mit.edu> keith@EXPO.LCS.MIT.EDU (Keith Packard) writes: > >> No /dev/bw* devices are defined. >> I am not running on top of Sun windows, so macro SUN_WINDOWS is undefined. >> The release 3 server worked fine. >> I compiled with version 1.36.1 of gcc. > >Every ioctl call in your distribution is not working because the person who >installed gcc neglected to run fixincludes on the machine you're building R4 >with. > >Run 'fixincludes' from the gcc distribution and rebuild the X distribution. >You could search the entire X tree for users of ioctl and rebuild those >files, but it is sufficient just to 'make clean; make' from the top level >(if a bit slower). This assumption is not necessarily valid. I tried building R4 with gcc 1.36, and got the ioctl errors. I then ran fixincludes, did another make World, and got the same thing. fixincludes had decided that there was nothing wrong with with my ioctl.h and omitted it from gcc-includes. Since I'm not sure what a "fixed" ioctl.h should look like, I punted and rebuilt everything with cc. You'll be happy to know (probably) that R4 runs beautifully on a Sun-2/120 under SunOS3.4. The mfb server is noticeably faster, which is sort of important on a machine of this vintage. I was particularly pleased that you included the UseInstalled code in the Imake rules. SHAPES is also very slick. Bravo, people! Very nice work. -- Dave Mack even if it did take eleven hours to compile. Each time.