braun@m10ux.UUCP (06/06/87)
I am bringing up the V10R4 X Windows on a Sun 3/150, (I think it's a 150... A vertical grey box on the floor w/ disks), and apperently the server does not support the X_StippleFill message (#54). This keeps the Berkeley VEM Graphics editor from working correctly. Does anyone know of an improved version of the Sun server? The README,CHANGES,BUGS, and man files all give a slightly different story about what's going on. Excuse me if this is a naive question, I have 2 days experience with the software. P.S: The VEM/X combination is extremely impressive. -- Doug Braun AT+T Bell Labs, Murray Hill, NJ m10ux!braun 201 582-7039
mike@thalamus.bu.edu (Michael Cohen) (08/25/89)
This concerns a bug I discovered in X11R3 Sun Server Code. The problems
concern the interactions in the initialization of a frame buffer using
/dev/bwtwo0 for an X server. The problem concerns the interaction
between the routines ../server/ddx/sun/{sunInit.c,sunBW.c}.and the fix is
described below. The bug bug was detected on a Sun386i/150 with 4MB of memory.
The routine sunOpenFrameBuffer in sunInit.c opens the appropriate
frame buffer and does a FBIOGTYPE ioctl correctly returning the frame buffer
description in the structure fbType. However, when memory is mapped
to the frame buffer in the following mmap calls reference is not made
the appropriate value returned by the ioctl telling the size of the
frame buffer , fbtype.fb_size, but the
reference is made to values defined in system include files
<sundev/bw2reg.h> in particular to BW2_FBSIZE, and BW2_FBSIZE_HIRES
indirectly referenced through sizeof(<variable>) where
<variable> is defined by a typedef in terms of the above quantities.
Although this turns out to be fine for large screen devices, for small
screen devices (namely my 386i/150's), the initial mmap of the frame
buffer returns with the error message, "Mapping BW2: No such device or
address", because the frame buffer for the small screen is
significantly smaller than the amount of memory which one is requesting to map.
The fix is to use the quantity returned by the FBIOGTYPE ioctl, fbType.fb_size
or if necessary some integral multiple in machine pages in subsequent
mmap calls.
Enclosed is a small piece of code which simulates the action of the Xsun
server. Thanks to Phil Budne (budd@bu-it.bu.edu), for help in testing
the server. This code generates the no error message on large
screen devices but fails on small screen (1024 X 768) devices.
-mike
-----------------------------test routine------------------------------
# include <stdio.h>
# include <sys/ioctl.h>
# include <sun/fbio.h>
# include <sundev/bw2reg.h>
# include <sys/types.h>
# include <sys/mman.h>
# include <fcntl.h>
# include <errno.h>
# define Error perror
typedef struct bw2
{
u_char image[BW2_FBSIZE]; /* Pixel buffer */
}
BW2, BW2Rec, *BW2Ptr;
main() {
extern caddr_t mmap();
int fd;
BW2Ptr fbptr = NULL;
struct fbtype fb;
fd = open( "/dev/fb", O_RDWR, 0 );
# define P(f) printf("f: %d\n", fb.fb_/**/f)
ioctl( fd, FBIOGTYPE, &fb );
P(type);
P(height);
P(width);
P(depth);
P(cmsize);
P(size);
fbptr = (BW2Ptr) mmap((caddr_t) 0, sizeof(BW2),
PROT_READ | PROT_WRITE,
MAP_SHARED | _MAP_NEW,
fd, (off_t) 0);
if ((int) fbptr == -1)
{
Error("mapping BW2");
(void) close(fd);
}
}
--
Michael Cohen ---- Center for Adaptive Systems
Boston University (617-353-7857)
Email: mike@bucasb.bu.edu
Smail: Michael Cohen
Center for Adaptive System
Department of Mathematics, Boston University
111 Cummington Street
Boston, Mass 02215brossard%litsun2.epfl.ch@MITVMA.MIT.EDU (Alain Brossard) (11/08/89)
[Sent: Wed. 08/Nov./89 Time: 10:56]
Whenever I reach some magic limit having to do with the
number of windows on the screen, I get the following message when
I try to start a new application:
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.
I presume it is some kind of internal limit, can somebody either
give me a fix or tell me which function/files to modify or at least
what pattern to use with grep to find out from where the problem originates.
E-mail me and I'll post the answer(s).
Alain Brossard
brossard@litsun.epfl.chrws@EXPO.LCS.MIT.EDU (Bob Scheifler) (11/08/89)
Whenever I reach some magic limit having to do with the number of windows on the screen, I get the following message when I try to start a new application: You haven't supplied enough information. Please be more detailed in future messages. What version of the OS are you running? Which release of X11? Do you really mean "windows on the screen", or do you actually mean "connections to the server"? How many windows and connections are there when things start to fail? Is it consistently this number? (Please post details to xpert, not to me directly.)
brossard%litsun.epfl.ch@MITVMA.MIT.EDU (Alain Brossard) (11/08/89)
In article <891108154201.206000b6@SIC.Epfl.CH> you write: > > Whenever I reach some magic limit having to do with the > number of windows on the screen, I get the following message when > I try to start a new application: > >You haven't supplied enough information. Please be more detailed in >future messages. Oups, that's what happens when we do to many things at a time so: X11R3, patch level 9 + Purdue speed-ups, on a Sun 3/60 running sunOS3.5 or 4.0 (occurs on both). The message occurs after I have the following on the screen: 14 xterms doing various things, 1 xload 1 xbiff 1 xpostit with 15 notes (independant windows) Now if I run xterm: litsun2[1]$ xterm 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. or xplaces: litsun2[1]$ xplaces 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. Just putting a bunch of xterms will do it. I'm not running out of pty's and I should point out that some of those xterms were not started on the same machine. Display is litsun5:0.0, while the example above was started on machine litsun2. I have recently recompiled X11 with gcc but this had no impact on this problem. I can also add that if I kill xpostit with all its windows, it allows me to restart only one program and not more than that. Alain Brossard brossard@litsun.epfl.ch
bob@MorningStar.Com (Bob Sutterfield) (11/09/89)
It sounds as if he needs to increase NOFILE in <sys/param.h> and recompile his kernel from source. Or kill off a few clients, whichever seems easier.
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (11/09/89)
> X11R3, patch level 9 + Purdue speed-ups, on a Sun 3/60 running > sunOS3.5 or 4.0 (occurs on both). > The message occurs after I have the following on the screen: > 14 xterms doing various things, > 1 xload > 1 xbiff > 1 xpostit with 15 notes (independant windows) Ah, 17 server connections. What is almost certainly happening is that the X server is running out of file descriptors. Its limit is 20; subtract 3 for stdin, stdout, and stderr, and you get 17. (Where have I seen that number before? :-) Under release 3.5, you can't do anything about this unless you have kernel source, and even then, you can't raise it higher than 31 or maybe 32. Under release 4, you can probably raise it much higher, but I don't know more than that - the kernel architecture is all different and I don't know how the file descriptor handling works. Someone from Sun can probably tell us (hint hint?). If you really really have to raise this limit, it's possible to hack the server to spawn off multiplexor processes to help handle all the network connections. I've never tried it, but feel certain it must be possible. It might even be fairly easy. Someday I suppose I shall have a stab at it; it certainly is the sort of thing that Ought To Be Done. (X group: fixed in R4 maybe? If I do it for R3, would it be of any use for R4?) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (11/09/89)
If you really really have to raise this limit, it's possible to hack
the server to spawn off multiplexor processes to help handle all the
network connections.
Seems like a complete waste of time. Better to upgrade to an OS with a decent
number of file descriptors.