ballou@uselss.enet.dec.com (Kenneth R. Ballou) (09/28/90)
First, please accept my apologies if this has been discussed before. I'm
afraid I haven't had time to keep up with the newsgroup.
I'm running R4 with patches through #14 on a VAXstation 2000/GPX running
ULTRIX (now 4.0, was 3.1 -- the behavior is the same in both cases). I used
gcc version 1.37.1 as the compiler. Also, I have applied patches from Tim
Theisen which were posted early May to this newsgroup. These patches are
supposed to correct the Xqdss server hanging, and they do help a bit.
Here are the peculiarities I have observed. I'm wondering if anyone else has
seen them, or if I'm losing my mind (yes, I realize those two events are not
necessarily related! :-)
1. The server frequently hangs and soaks up CPU cycles. I have tracked down
what it is doing; it is in Flush_fifo in server/ddx/dec/qdss/libtl/tldma.c.
Specifically, it is stuck on line 617:
if (wait_flag == TRUE) {
while (*sg_int_flag != 1);
while ((sgfcc->fwused || (*change_section == 1)); /* ?? */
while ( (AdderPtr[STATUS] & ADDRESS) != ADDRESS);
}
Line 617 is the line with the /* ?? */ comment. (That comes from the code,
though it sums up my reaction as well :-) It seems sgfcc->fwused is not
willing to become zero.
When this happens, the error log entry gets two entries that look like:
********************************* ENTRY 1. *********************************
----- EVENT INFORMATION -----
EVENT CLASS OPERATIONAL EVENT
OS EVENT TYPE 250. ASCII MSG
SEQUENCE NUMBER 131.
OPERATING SYSTEM ULTRIX 32
OCCURRED/LOGGED ON Thu Sep 27 16:51:04 1990 EDT
OCCURRED ON SYSTEM uselss
SYSTEM ID x08000000
SYSTYPE REG. x04040002
FIRMWARE REV = 4.
PROCESSOR TYPE KA410
MESSAGE
g_write_id: adrs = 60 data = 1
********************************* ENTRY 2. *********************************
----- EVENT INFORMATION -----
EVENT CLASS OPERATIONAL EVENT
OS EVENT TYPE 250. ASCII MSG
SEQUENCE NUMBER 130.
OPERATING SYSTEM ULTRIX 32
OCCURRED/LOGGED ON Thu Sep 27 16:51:04 1990 EDT
OCCURRED ON SYSTEM uselss
SYSTEM ID x08000000
SYSTYPE REG. x04040002
FIRMWARE REV = 4.
PROCESSOR TYPE KA410
MESSAGE
sg_write_id: timeout trying to write
_to VIPER
I can reproduce this by running DECwrite on a VMS node displaying to the
VAXstation 2000/GPX (via DECnet).
2. I am using twm as my window manager. Occasionally, when I click on the
iconify button of an open window, the watch cursor comes up, and that's all.
The server starts eating CPU cycles. However, I have not determined where the
server is looping in this case.
3. The xman icon is fascinating! Its appearance depends on where I move the
icon! The best description I can give is that it appears as though the plane
is tiled with the xman icon bitmap. Then, the image that appears in the icon
looks as though I'm looking at a random chunk of this tiling. If I move the
icon and then select "refresh screen" from my twm menu (or run xrefresh), the
icon changes appearance! (I'm sorry; I realize I haven't described this
clearly.)
4. I have xclock running (in digital mode) in the upper left corner of my
screen. If I position an xterm icon over the xclock window, the text in the
xclock window disappears. In fact, the closer to the left edge of the screen I
position the icon, the more the text disappears. In the worst case, I just
have a few dots left where the xclock window text used to be.
5. Occasionally, a newly-created window will have a mangled icon. Instead of
a bitmap, the icon looks like a solid black square with white diagonal
stripes.
Did I possibly do something wrong while building R4? Or has this been seen
elsewhere?
- Ken
--
Kenneth R. Ballou ballou@vmsdev.enet.dec.com
Digital Equipment Corporation ...!decwrl!vmsdev.enet!balloudaemon@decwrl.dec.com R. Ballou) (10/03/90)
First, please accept my apologies if this has been discussed before. I'm
afraid I haven't had time to keep up with the newsgroup. Also, if this is a
reposting, I also apologize.
I'm running R4 with patches through #14 on a VAXstation 2000/GPX running
ULTRIX (now 4.0, was 3.1 -- the behavior is the same in both cases). I used
gcc version 1.37.1 as the compiler. Also, I have applied patches from Tim
Theisen which were posted early May to this newsgroup. These patches are
supposed to correct the Xqdss server hanging, and they do help a bit.
Here are the peculiarities I have observed. I'm wondering if anyone else has
seen them, or if I'm losing my mind (yes, I realize those two events are not
necessarily related! :-)
1. The server frequently hangs and soaks up CPU cycles. I have tracked down
what it is doing; it is in Flush_fifo in server/ddx/dec/qdss/libtl/tldma.c.
Specifically, it is stuck on line 617:
if (wait_flag == TRUE) {
while (*sg_int_flag != 1);
while ((sgfcc->fwused || (*change_section == 1)); /* ?? */
while ( (AdderPtr[STATUS] & ADDRESS) != ADDRESS);
}
Line 617 is the line with the /* ?? */ comment. (That comes from the code,
though it sums up my reaction as well :-) It seems sgfcc->fwused is not
willing to become zero.
When this happens, the error log entry gets two entries that look like:
********************************* ENTRY 1. *********************************
----- EVENT INFORMATION -----
EVENT CLASS OPERATIONAL EVENT
OS EVENT TYPE 250. ASCII MSG
SEQUENCE NUMBER 131.
OPERATING SYSTEM ULTRIX 32
OCCURRED/LOGGED ON Thu Sep 27 16:51:04 1990 EDT
OCCURRED ON SYSTEM uselss
SYSTEM ID x08000000
SYSTYPE REG. x04040002
FIRMWARE REV = 4.
PROCESSOR TYPE KA410
MESSAGE
g_write_id: adrs = 60 data = 1
********************************* ENTRY 2. *********************************
----- EVENT INFORMATION -----
EVENT CLASS OPERATIONAL EVENT
OS EVENT TYPE 250. ASCII MSG
SEQUENCE NUMBER 130.
OPERATING SYSTEM ULTRIX 32
OCCURRED/LOGGED ON Thu Sep 27 16:51:04 1990 EDT
OCCURRED ON SYSTEM uselss
SYSTEM ID x08000000
SYSTYPE REG. x04040002
FIRMWARE REV = 4.
PROCESSOR TYPE KA410
MESSAGE
sg_write_id: timeout trying to write
_to VIPER
I can reproduce this by running DECwrite on a VMS node displaying to the
VAXstation 2000/GPX (via DECnet).
2. I am using twm as my window manager. Occasionally, when I click on the
iconify button of an open window, the watch cursor comes up, and that's all.
The server starts eating CPU cycles. However, I have not determined where the
server is looping in this case.
3. The xman icon is fascinating! Its appearance depends on where I move the
icon! The best description I can give is that it appears as though the plane
is tiled with the xman icon bitmap. Then, the image that appears in the icon
looks as though I'm looking at a random chunk of this tiling. If I move the
icon and then select "refresh screen" from my twm menu (or run xrefresh), the
icon changes appearance! (I'm sorry; I realize I haven't described this
clearly.)
4. I have xclock running (in digital mode) in the upper left corner of my
screen. If I position an xterm icon over the xclock window, the text in the
xclock window disappears. In fact, the closer to the left edge of the screen
I position the icon, the more the text disappears. In the worst case, I just
have a few dots left where the xclock window text used to be.
5. Occasionally, a newly-created window will have a mangled icon. Instead of
a bitmap, the icon looks like a solid black square with white vertical
stripes.
Did I possibly do something wrong while building R4? Or has this been seen
elsewhere?
- Ken
--
Kenneth R. Ballou ballou@vmsdev.enet.dec.com
Digital Equipment Corporation ...!decwrl!vmsdev.enet!ballou
D. Allen [CGL]) (10/09/90)
>I'm running R4 with patches through #14 on a VAXstation 2000/GPX running >ULTRIX (now 4.0, was 3.1 -- the behavior is the same in both cases). >1. The server frequently hangs and soaks up CPU cycles. Yes, we see this on our MVII/GPX systems. "Timeout trying to write to VIPER" shows up in the syserr files. "echo hi >/dev/console" sometimes unsticks things, sometimes makes them worse. XDVI is notorious for triggering this bug. Never happens on monochrome systems. -- -IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada