[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:	DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:	See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:	STAR::VATNE

Created:	Mon Oct 30 1989
Last Modified:	Mon Dec 31 1990
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3726
Total number of notes:	19516

1535.0. "Session Manager stuck in MUTEX state" by GOIVIT::ALDEN (Ken Alden) Thu Oct 05 1989 07:41

    I'm running FT2 V2 DECwindows and for the second time in about two
    weeks, my session manager is in MUTEX state. Is there any way to find
    out what the process is waiting for?
    
    From SDA, the process looks like this, but I doubt this helps much.
    
----------------------------------------------------------
Process status:  02040001   RES,PHDRES

PCB address              8028E5E0    JIB address              803F86A0
PHD address              8068CA00    Swapfile disk address    00000000
Master internal PID      00010010    Subprocess count                0
Internal PID             00010010    Creator internal PID     00000000
Extended PID             00000050    Creator extended PID     00000000
State                       MUTEX    Termination mailbox          0000
Current priority                9    AST's enabled                KESU
Base priority                   4    AST's active                 NONE
UIC                [00200,000201]    AST's remaining                96
Mutex count                     0    Buffered I/O count/limit       96/100
Waiting EF cluster              0    Direct I/O count/limit        100/100
Starting wait time       1B001B1B    BUFIO byte count/limit        176/1216
Event flag wait mask     803F86A0    # open files allowed left      92
Local EF cluster 0       C3000000    Timer entries allowed left     20
Local EF cluster 1       80000000    Active page table count         0
Global cluster 2 pointer 00000000    Process WS page count        1525
Global cluster 3 pointer 00000000    Global WS page count          913

    The process entered this state after starting up an application
    from the Applications menu.
    
    The first time I saw the SM in MUTEX state was when I was trying
    to login in the morning, and the pause window wouldn't react after
    typing in my password. 
    
    If a dump is necessary, then we're out this time, as my dump file
    is only six blocks, but I can try to squeeze the disk space and
    build a dump file for the next time around, if that is the only
    way to find out what's going wrong. 
    
    Thanks,
    -Ken

T.R	Title	User	Personal Name	Date	Lines
1535.1	Dumps to Pagefile don't waste so much space...	MUNEDI::BRUNNER	Hermann Brunner	`Thu Oct 05 1989 10:16`	8
	6 - blocks Dumpfile ??? You would possibly be better off when deleting the SYSDUMP.DMP completely and let the dump go into the pagefile ( if this one is on SYS$SYSDEVICE:...) Don't forget to set DUMPSTYLE and SAVEDUMP to "1".... sorry no comment on the MUTEX problem - don't know enough about DECWindows H.B.
1535.2		DAVIDS::KUBELKA	David Kubelka, Valbonne 828-5421	`Thu Oct 05 1989 10:32`	29
	Are you having this problem when you quit the session if yes, I know what you are talking about. I don't know by what this problem is caused I only know how to get rid of the process. What you do is in SDA SHOW PROC/CHANNEL you will find that the session manager has one mailbox, just do a $ TYPE MBAXX: from the output I'm getting I would say it's the termination mailbox. After that you process will disapear. One the subject, In DECW V1 the working set for the session manager was limited to 200 pages. This was done in DECW$SYLOGIN.COM so I commented it out. Now I installed T5.3 and when I had my after installation cleanup I found out that DECW$SYLOGIN.COM had this set work... commented out. I thought great but later one the first time I deiconiced the session manager it took me about 50 seconds before I could see what is in the session manager window. And to my surprise the working set was limited to 200 pages again. After some searches through a few command files I found that the working set is now limited in DECW$STARTSM.COM. I'm not goning to say what I think about having my session manager limited to 200 pages, but I would like to know why somebody did this. System tunning on a workstation is somewhat different then on a time sharing system. If I click on the icon the only think of interest is how fast is the window redrawn I don't care at all what effect this has to other processes running on the system. Most system I've looked at, never had a process swapped out even though the process wasn't used in the last three hours. But the LSE session that was currently used would have been a lot faster with 4 or 5 MBs more. best regards David Kubelka
1535.3	Looks like a quota problem...	GOFER::HARLEY	You can't fight in here, this is the War Room!	`Thu Oct 05 1989 11:23`	15
	re .0 I'd say that you have a quota problem, since the EF wait mask is the address of the JIB. Try formatting the SM's JIB the next time it hangs to see what you ran out of. re .1 If you use your Pagefile to hold crash dumps in, it should be at least as large as MEMSIZE + 2000 or so; DUMPSTYLE=1 will try to fill up the file that crash dumps go to, and if it fills up the pagefile you'll lose the dump (and errorlog buffers) when you reboot. /Harley
1535.4	Try UAF/Pgflquo	KASINO::TALLETT	Just one more bug to fix...	`Mon Oct 16 1989 15:21`	10
	Hi there! I was tracking a MUTEX wait with JIB address a while back and it turned out to be pagefile quota in the UAF. I guess if your pagefile were to small it would cause the same problem? Regards, Paul Tallett, CEC Karlsruhe
1535.5	Found, we hope	DECWIN::FISHER	Burns Fisher 381-1466, ZKO3-4/W23	`Thu Oct 19 1989 22:18`	9
	Karen apparently just found a problem that causes symptoms like this. The quota seems to be bytlim. It is related to creating DECterms (and maybe other applications). She said that each time you create one you loose (a few hundred?) bytes. I can't tell you when it will be fixed. She just found it this afternoon. Burns
1535.6	This is the same one I saw about a month ago...	GOIVIT::ALDEN	Ken Alden	`Wed Oct 25 1989 14:03`	9
	I does happen with one's bytlm too low (<32K) and VMS 5.3. I didn't have more than 2 DECterms up, just a "reasonable" number of applications. I always saw the problem with the MUTEX occur during a Pause Session...(It wouldn't ever come out of the pause.) My bytlm is now at 64K and I haven't seen the problem reoccur. -Ken
1535.7	BYTLM is the problem...	NITMOI::PESENTI	Only messages can be dragged	`Wed Dec 20 1989 14:39`	18
	Well, I set my BYTLM at 64K, and the problem virtually went away. Then our cluster, where most of my applications run, developed a problem. After about 10-15 minutes, it hung up the DECwindows links. That problem finally got solved, but in the meantime, it caused me to restart my remote sessions about every 15 minutes. This really aggravated the MUTEX problem again. It turns out, each time I start ANY application, the session manager process get a 1200 byte hit on BYTLM. (A bit more than a few hundred, I'd say.) My workaround for now is to monitor the SM's BYTLM regularly, and quit the session when the number gets low. I hope this problem can be fixed, and soon! -JP
1535.8	fixed	STAR::BROUILLETTE		`Thu Dec 21 1989 16:54`	3
	Already fixed for the next application bug fix release of DECwindows.
1535.9		NITMOI::PESENTI	Only messages can be dragged	`Fri Dec 22 1989 09:22`	5
	I don't mean to be dense, but could you translate the phrase: next application bugfix release of DECwindows into something more tangible? (E.g., VMS V5.4, 5.5, etc.)
1535.10		STAR::BROUILLETTE		`Fri Dec 22 1989 11:18`	7
	Sorry, I didn't mean to be evasive, but I wasn't sure if the release had a number yet, and if it did, whether or not I could mention the number in the notes file. I have done some checking and I believe that this fix will be in VMS V5.4.