Path: utzoo!attcan!uunet!wuarchive!cs.utexas.edu!bcm!lib!soma!concurrent-request
From: benf@mips.com (Ben Fathi)
Newsgroups: comp.sys.concurrent
Subject: Re: rtu 5.0 crashes
Message-ID: <4152@lib.tmc.edu>
Date: 3 Oct 90 23:57:24 GMT
Sender: usenet@lib.tmc.edu
Lines: 41
Approved: concurrent@soma.neusc.bcm.tmc.edu
Nntp-Posting-Host: cortex.neusc.bcm.tmc.edu



>One of our systems here, running RTU 5.0 is experiencing rather
>frequent and (thus far) unexplained crashes. In general, the
>crashes seem occur when medium-to-large x-clients are running,
>usually on NCD X-terminals. The console reports something
>like this:

>lomap: rmap overflow, lost 129-131
>lomap: rmap overflow, lost 133-134
> ....
>lomap: rmap overflow, lost 154-155
>iomalloc going to sleep: size=0x3000

These messages are from the I/O mapping code. This code is called
by device drivers to map addresses on the memory bus to addresses
on the I/O bus (either Multibus or VMEbus depending on your machine
type). In this case, it sounds like you have a Multibus based
machine (the VME code prints slightly different messages) which means
wither a 5300/5400 or 5600/5700. The messages also mention "lomap"
which is a piece of the I/O maps used for 20-bit devices. 

There is one of two possible explanations:

1. You have lots and lots of devices in the system and are using
up all the I/O map registers for DMA purposes.

2. You have a driver for a 20-bit Multibus device that's allocating I/O
map registers to do DMA but is failing to release them correctly when
the DMA is complete.

My guess is that number 2 is the problem. 

	ben

PS: We have seen (1) happen on a couple of systems, but this usually requires
    a lot more than a few minutes of "puttering around" that you mentioned.

Articles to: concurrent@soma.bcm.tmc.edu or uunet!soma.bcm.tmc.edu!concurrent
Administrative stuff: concurrent-request@soma.bcm.tmc.edu
Stan Barber, Moderator