Hi, regarding your problem I guess it is not a problem related only to the somewhat high amount of memory. I've 2.2.14 running with 3*64MB with no problems. But sorry, why do you mention 132 MB and not 128 MB? Is perhaps one module with ECC or something like that? In that case I seem I remember there are problems with mixed configuration. If I were you I would give a try to another DIMM. regards, Stefano "Paul W. Abrahams" ha scritto:
Here is the text of a message I sent to the maintainter of the ext2fs filesystem. I think it would be of interest to this group, especially if anyone here has had a similar experience.
1. Summary: Ext2fx implosion when RAM added
2. Description: My computer is a Pentium II with a Tyan S1590 Trinity 100AT motherboard. I am running SuSE Linux 6.2 with the 2.2.14 kernel. I had 64MB of SIMM memory installed. Recently I installed an additional 64MB in the form of a single (Kingston PC100) DIMM module, bringing the total memory to 132MB. When I rebooted the computer, one of my Linux filesystems generated massive fsck errors, apparently related to a bad superblock.
At first I assumed that there was a hardware problem, but I no longer believe that. To test for problems with the disk itself, I recreated the partition with the -c option. No bad blocks were found. I also repartitioned the entire drive and moved the partition in question to another location, while retaining its size of about 3GB (see below). That made no difference. In addition, Windows continued to function perfectly, and the Windows partitions passed exhaustive Norton tests. I also formatted the same space as the Linux partition as a Windows partition and ran Norton on it, with no errors.
As to the memory, the ext2fs misbehavior is extremely consistent. I have no specific software for memory testing, but the bootup memory scans show no problems, and aside from this one specific problem with ext2fs, I have seen no indication of any malfunctions in either Linux or Windows. Were the memory unreliable, I would have expected to see other indications of misbehavior.
Here is the procedure that I carried out a number of times, always with the same results:
1. I reformatted the hdc5 partition with mkfs, using an inode density of 4096 (the SuSE default).
2. I installed the basic packages that gave me a running system. I then rebooted the system and did an ``fsck -n /dev/hdc5' passive check. The check showed no errors. I repeated the reboot and fsck check a couple of times.
3. Using the SuSE Yast configuration program, I restored the system files from CD-ROMs. Nearly all the files went into /usr, which I had placed on hdc5. After restoring the files, I repeated the fsck check, again with no errors.
4. I rebooted the system. This time the check showed massive errors in the hdc5 filesystem.
When I removed the additional 64MB memory and repeated the procedure, there was no difficulty with the final check and my system was working properly.
My observation is that the error seems to be caused by the conjunction of three circumstances: a large (3GB) partition, a large RAM installation (132MB), and the use of a significant portion of the available space within the partition. It is triggered either by the shutdown procedure or the bootup procedure, but I don't know which.
3. Keywords: kernel, ext2fs, RAM
4. Kernel version: 2.2.14
5. Additional information: Here is the output of fdisk for the drive:
Disk /dev/hdc: 255 heads, 63 sectors, 1027 cylinders Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks Id System /dev/hdc1 1 64 514048+ 18 AST Windows swapfile
/dev/hdc2 65 1027 7735297+ f Win95 Ext'd (LBA) /dev/hdc5 65 447 3076416 83 Linux /dev/hdc6 448 511 514048+ e Win95 FAT16 (LBA) /dev/hdc7 512 766 2048256 b Win95 FAT32
Unfortunately I can't give you the kernel configuration since I lost it when the /usr filesystem (including /usr/src/linux, of course) was clobbered by the first failure.
The BIOS that comes with the Tyan motherboard has an option called ``OS Select for DRAM > 64MB'', which selects either OS/2 or non-OS/2. I tried it both ways and it made no difference.
Paul Abrahams abrahams@acm.org
-- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
-- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/