---559023410-429904914-932646431=:12950
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 22 Jul 1999, Bob_Tracy wrote:
> Matthias Hanisch wrote:
> > > On Wed, 21 Jul 1999, Bob_Tracy wrote:
> > > > "Out of memory -- System halted".
> >
> > The cause of the problem was that the huffman
> > code lookup table grew too much with some byte patterns in the kernel
> > image. Minimal changes in kernel source code made the problem disappear.
> > I second this to raise the heap size a bit (IMHO 0x2400 should be enough).
>
> That took care of the problem. Evidently, what Matthias described is
> exactly what occurred when I added the Cyrix coma bugfix code back into
> 2.3.10, i.e., the kernel compression characteristics were changed just
> enough to allow things to work. The same trick wasn't effective to
> allow 2.3.11 to boot in my case.
>
> Let's *do* raise the heap size a bit. 0x3000 was effective for me.
> Didn't try a smaller increment.
>
> FYI, the problem has shown up on another machine I use that has the
> "officially blessed" compiler setup: gcc-2.7.2.3. This isn't a gcc
> issue, nor is it a Cyrix-specific issue as I originally thought.
FYI, too, I've looked through my archives and here is a little patch for
gzip's inflate.c (not the kernel inflate.c!!) which prints the needed
amount of heap memory for a gzip archive to stderr.
So you can test it with your kernel images (on $$tmppiggy.gz, just remove
the deletion command in arch/i386/boot/compressed/Makefile)...
BTW, zlib has a limit of 1440 for huffman table length, which means we
should have a heap size of 0x2d00 (8 bytes for struct huft).
Patch is attached (against 2.2.5, but this shouldn't matter...).
Matze
P.S.: I've tested some arbitrary gzip files on my machine and a usage of
more than 8k heap occurs amzingly often (> 2%)...
--
Matthias Hanisch office: matze@camline.com private: matze@pingu.franken.de
+49 8137 935-219 +49 8441 82387
"CAPS - Software from Experts for Experts"
---559023410-429904914-932646431=:12950
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="gzip.diff"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.SC5.4.10.9907221427110.12950@cam8.camline.com>
Content-Description: print max heap usage
Content-Disposition: attachment; filename="gzip.diff"
LS0tIGluZmxhdGUuYy5vcmlnCVRodSBKdWwgMjIgMTM6Mzg6NTYgMTk5OQ0K
KysrIGluZmxhdGUuYwlUaHUgSnVsIDIyIDEzOjQ2OjUzIDE5OTkNCkBAIC05
NDcsOCArOTQ3LDcgQEANCiANCiANCiAgIC8qIHJldHVybiBzdWNjZXNzICov
DQotI2lmZGVmIERFQlVHDQotICBmcHJpbnRmKHN0ZGVyciwgIjwldT4gIiwg
aCk7DQotI2VuZGlmIC8qIERFQlVHICovDQorICBmcHJpbnRmKHN0ZGVyciwg
IjwldT4gaHVmdHMsIDwldT4gaGVhcCBzaXplIG5lZWRlZFxuIiwNCisJaCwg
aCAqIHNpemVvZihzdHJ1Y3QgaHVmdCkpOw0KICAgcmV0dXJuIDA7DQogfQ0K
---559023410-429904914-932646431=:12950
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="heap.diff"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.SC5.4.10.9907221427111.12950@cam8.camline.com>
Content-Description: Raise heap limit
Content-Disposition: attachment; filename="heap.diff"
LS0tIGxpbnV4L2FyY2gvaTM4Ni9ib290L2NvbXByZXNzZWQvbWlzYy5jLm9y
aWcJVGh1IEp1bCAyMiAxNDowOToyNCAxOTk5DQorKysgbGludXgvYXJjaC9p
Mzg2L2Jvb3QvY29tcHJlc3NlZC9taXNjLmMJVGh1IEp1bCAyMiAxNDoxMDoz
NSAxOTk5DQpAQCAtMTA0LDcgKzEwNCw3IEBADQogI2RlZmluZSBMT1dfQlVG
RkVSX1NUQVJUICAgICAgMHgyMDAwDQogI2RlZmluZSBMT1dfQlVGRkVSX0VO
RCAgICAgICAweDkwMDAwDQogI2RlZmluZSBMT1dfQlVGRkVSX1NJWkUgICAg
ICAoIExPV19CVUZGRVJfRU5EIC0gTE9XX0JVRkZFUl9TVEFSVCApDQotI2Rl
ZmluZSBIRUFQX1NJWkUgICAgICAgICAgICAgMHgyMDAwDQorI2RlZmluZSBI
RUFQX1NJWkUgICAgICAgICAgICAgMHgyZDAwCS8qIHNhbWUgYXMgaW4gemxp
YiAqLw0KIHN0YXRpYyBpbnQgaGlnaF9sb2FkZWQgPTA7DQogc3RhdGljIHVj
aCAqaGlnaF9idWZmZXJfc3RhcnQgLyogPSAodWNoICopKCgodWxnKSZlbmQp
ICsgSEVBUF9TSVpFKSovOw0KIA0K
---559023410-429904914-932646431=:12950--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/