Messages in this thread | | | Date | Fri, 2 May 1997 10:29:47 -0700 (PDT) | From | David Whysong <> | Subject | Re: Signal 7 and "Couldn't get a free page..." |
| |
On Fri, 2 May 1997, Hubert Mantel wrote:
> On Thu, 1 May 1997, David Whysong wrote: > > > > > SIGBUS: ayiee, couldnt allocate page table. > > > > Changing 16 --> 48 in free_area_init() of linux/mm/page_alloc.c solves > > this problem on my machine. I think this should go into 2.0.31. > > I changed 128 --> 200 (echo "200 300 400" > /proc/sys/vm/freepages) and > still had the problem. Increasing these values only makes the problem show > up not so often, but it does _NOT_ solve the problem.
I agree; I did
# echo "128 256 512" > /proc/sys/vm/freepages # make zImage MAKE="make -j"
And promptly got a signal 7. I do NOT understand why changing 16 --> 48 in free_area_init() has any effect on my machine; the relevant code is:
i = (end_mem - PAGE_OFFSET) >> (PAGE_SHIFT+7); if (i < 16) i = 16;
I have 32M of RAM, so if end_mem is 32M = 2^25, then i should be (2^25-0) >> (12+7) = 64
So on my machine (assuming I understand this code correctly, which is pretty far-fetched) i>16 anyway and changing from 16 to 48 shouldn't do anything at all. It does, though... my system has been rock-solid ever since I made the change.
Obviously my comment that this should go into 2.0.31 was premature; I need to understand just why this little change seems to work for me in the first place.
> I tried the tests with the old buffer.c code from 2.0.29: The problem > showed up not so often, but still existed.
I don't know when this problem first showed up; for a long time I thought it was flaky hardware and so I lived with it. Now I'm not so sure.
Dave
David Whysong dwhysong@physics.ucsb.edu PGP Key fingerprint = 9D 51 6E CE 5F 38 F0 E7 56 3C 01 45 CF 03 9F 4A Finger for PGP public key.
| |