Reading 4MB core dumps: panic vmdrum NDMAP

[chris at umcp-cs.UUCP]

I thought my reply might be of general interest (especially to those
interested in increasing the maximum size of a process under 4.1).

[Begin forwarded message]

From:     Chris Torek <chris at umcp-cs>
Subject:  Re: panic vmdrum NDMAP
To:       messick at oregon-state

Sounds like someone changed DMMIN, DMMAX, DMTEXT, the allocation
algorithm, and/or the maximum process size, without changing NDMAP.
The swap area is broken up into a bunch of little fragments with
NDMAP "starting points".  DMMIN is normally 32, DMMAX 1024; allocation
goes like this:

 #	size	total size	(sizes in ``core clicks'' = 512 bytes)
--	----	----- ----
 0	  32	   32
 1	  64	   96
 2	 128	  224
 3	 256	  480
 4	 512	  992
 5	1024	 2016
 6	1024	 3040
 7	1024	 4064
 8	1024	 5088
 9	1024	 6112
10	1024	 7136
11	1024	 8160
12	1024	 9184
13	1024	10208
14	1024	11232
15	1024	12256

[Pardon minor arith mistakes if any - I didn't recheck --ACT]

Now, half of 12256 is 6128, which is the maximum size in Kbytes of
a process under standard 4.1.  Whenever a process grows, one of
these little areas is allocated, from the head of the list at the
appropriate subscript.  If you have a different DMMIN, DMMAX, DMTEXT
(DMMAX for text pages), growth algorithm, or maximum process size,
then you need a different number of elements.

Simple, eh?

(Not by a long shot.)

Wait'll you hear about the bug in the swap allocation...:

Turns out that the code which computes the total space available
for swapping rounds UP!  Most of the swap*.c config files for 4.1
have a swap size of 33440 512-byte sectors.  This doesn't fit evenly
into the divisions set up in vmdrum.c.  The result is that if
someone tries to use all 1024 core clicks in the last segment
(fairly rare), the disk driver notices that the read or write
request extends past those 33440 sectors and sets B_ERROR, which
later causes the machine to crash with ``panic: hard I/O error in
swap''.

A fix was posted a while ago, and I can send you a copy if you need
it.

Hope this helps,
Chris
[End forwarded message]
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris.umcp-cs at CSNet-Relay