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/
Hi, just a few thoughts about that On Tue, Feb 08, 2000 at 19:24 -0500, Paul W. Abrahams wrote:
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
You didn't give the kernel a mem=... option telling it you have 132MB of RAM, did you? You only have 128 and if the kernel thinks you have 132, well...
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.
Have you tried to removing the old module and leaving the new one in? Does this cause errors? Ciao, Stefan -- 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/
On Tue, 8 Feb 2000, Paul W. Abrahams wrote:
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. 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.
I've got a similar setup with no problems. I originally had 64MB and added 64MB (doesn't that add up to 128MB? And 128MB isn't all that much memory these days), and I've got a 3.25GB /usr partitition in an extended partition which is almost full. The only difference is my /usr partition is in an extended partition with ID 5, not f, and I don't have an AST Windows swapfile partition (what is that anyway?) or any Windows partitions in the extended partition, just one a 1 gig primary FAT16 partition at the beginning of 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
Greg -- 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/
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/
spapin wrote:
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.
Actually, I believe the amount of memory is about 131MB. But it's not a problem. You mention 64MB, as most people do, but the actual amount is 65,536. Two such modules give you 131,072 - but again, people often refer to that as 128MB. When I composed the message I misremembered the number. Paul Abrahams -- 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/
"Paul W. Abrahams" wrote:
spapin wrote:
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.
Actually, I believe the amount of memory is about 131MB. But it's not a problem. You mention 64MB, as most people do, but the actual amount is 65,536. Two such modules give you 131,072 - but again, people often refer to that as 128MB. When I composed the message I misremembered the number.
Doesn't 1MB = 1024kB ? Yes, you are correct in that the DIMM has 65 536kB, but this is in fact equal to exactly 64MB. (1024 * 64 = 65 536) Remember, we work in binary ;-) I don't like telling people they're wrong, but just to clarify... Chris -- __ _ -o)/ / (_)__ __ ____ __ Chris Reeves /\\ /__/ / _ \/ // /\ \/ / ICQ# 22219005 _\_v __/_/_//_/\_,_/ /_/\_\ -- 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/
"Paul W. Abrahams" wrote:
spapin wrote:
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.
Actually, I believe the amount of memory is about 131MB. But it's not a problem. You mention 64MB, as most people do, but the actual amount is 65,536. Two such modules give you 131,072 - but again, people often refer to that as 128MB. When I composed the message I misremembered the number.
Actually, 2X64 meg dimms would be 128 megs, this is because a meg of ram or hd space is 1024 kb and when you multiply 1024 X 128 you get 131,072 which is in kb. If you put 131 or a 132 depending on what your bios shows at boot...Linux will just puke all over itself. I know this because I did it some years ago. If you don't have the correct mem that lilo is told you have it won't work. mem=128M is 131,072 kb... just my 0.02 -- Ben Rosenberg mailto:ben@whack.org SuSE 6.3 (2.2.14) ICQ UIN:49268667 ------------------------------------------------------------ " Success is how high you bounce when you hit bottom " --Gen. George Patton -- 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/
Ben Rosenberg wrote:
Actually, 2X64 meg dimms would be 128 megs, this is because a meg of ram or hd space is 1024 kb and when you multiply 1024 X 128 you get 131,072 which is in kb. If you put 131 or a 132 depending on what your bios shows at boot...Linux will just puke all over itself. I know this because I did it some years ago. If you don't have the correct mem that lilo is told you have it won't work. mem=128M is 131,072 kb...
Whatever the counting method, my BIOS automatically detects the amount of memory; there's no way to set it and therefore no way to get it wrong. The question of how to count RAM reminds me a little of the debates over whether the millenium begins on 1/1/2000 or 1/1/2001. On bootup, my BIOS announces that I have 131,072KB of memory; and I'll readily admit that it would probably have been clearer to refer to that in these posts as 128MB. The whole issue came up because I incorrectly remembered what the BIOS said when I was posting my original message about my disk problems. Paul Abrahams -- 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/
Well, I was actually talking about a lilo parameter so that Linux can see all the memory on MB's that Linux has problems with. I don't really care how one MB counts memory up in the post test, but I do know that 2-64 meg DIMMs are equal to 128 megs of ram and no more...the post test on most motherboards does show the kilobytes instead of megabytes which was all I was saying and it can be misconstrued as more memory then is actually there if the 1024 rules is not remembered. Yeah, I guess the millenium thing is a nice debate, but as far as memory counting is concerned..I really don't think there is much debate about it. I have been dealing with X86 PC's for a number of years and I never found it to be in question. No worries..it's cool..
Whatever the counting method, my BIOS automatically detects the amount of memory; there's no way to set it and therefore no way to get it wrong.
The question of how to count RAM reminds me a little of the debates over whether the millenium begins on 1/1/2000 or 1/1/2001. On bootup, my BIOS announces that I have 131,072KB of memory; and I'll readily admit that it would probably have been clearer to refer to that in these posts as 128MB.
The whole issue came up because I incorrectly remembered what the BIOS said when I was posting my original message about my disk problems.
-- Ben Rosenberg mailto:ben@whack.org SuSE 6.3 (2.2.14) ICQ UIN:49268667 ------------------------------------------------------------ " Success is how high you bounce when you hit bottom " --Gen. George Patton -- 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/
"Paul W. Abrahams" wrote earlier:
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
I won't repeat the previous message again, but I've run a memory tester (memtest86) and think it's unlikely the memory is at fault. And all the surface testing I've done makes it unlikely the disk is at fault. I'm wondering if possibly there might be a subtle bug in the unmounting procedures that cause the filesystem to become unsynchronized in certain (rare) environments, leaving essential data in a cache that's wiped out on shutdown. Any thoughts on that? Paul Abrahams -- 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/
On Wed, 09 Feb 2000, Paul W. Abrahams wrote:
"Paul W. Abrahams" wrote earlier:
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
I won't repeat the previous message again, but I've run a memory tester (memtest86) and think it's unlikely the memory is at fault. And all the surface testing I've done makes it unlikely the disk is at fault.
I'm wondering if possibly there might be a subtle bug in the unmounting procedures that cause the filesystem to become unsynchronized in certain (rare) environments, leaving essential data in a cache that's wiped out on shutdown.
Any thoughts on that?
Well...
Several months ago, I had a file system corruption problem and system hang
problem that I just *couldn't* figure out. memtest86 passed with flying
colors, every test I ran passed. I ran memtest86 for hours, ran disk tests,
etc.
Turned out to be a SIMM that wasn't properly seated. Still passed memtest86,
but somehow failed when the system was doing certain operations. Haven't
had a problem since I reseated the RAM.
-Nick
+-------------------------------+--------------------------------------------+
| /`--_ Nicholas R LeRoy | In a world without fences, Who needs Gates?|
|{ }/ Norland Corporation | ---- Experience Linux! ---- |
| \ * / W6340 Hackbarth Rd | http://www.linux.org | http://www.ssc.com |
| |___| Fort Atkinson, WI 53538 +--------------------------------------------+
| nick.leroy@norland.com | #include
On Wed, Feb 09, 2000 at 05:43:05PM -0500, Paul W. Abrahams wrote:
"Paul W. Abrahams" wrote earlier:
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
I won't repeat the previous message again, but I've run a memory tester (memtest86) and think it's unlikely the memory is at fault. And all the surface testing I've done makes it unlikely the disk is at fault.
I'm wondering if possibly there might be a subtle bug in the unmounting procedures that cause the filesystem to become unsynchronized in certain (rare) environments, leaving essential data in a cache that's wiped out on shutdown.
Hmmm. Did I miss it, or did you tell us you weren't using the append="MEM=128M" lilo boot statement? Just curious to see if that's involved in your predicament. -- Brad Shelton On Line Exchange http://online-isp.com -- 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/
Brad Shelton wrote:
On Wed, Feb 09, 2000 at 05:43:05PM -0500, Paul W. Abrahams wrote:
"Paul W. Abrahams" wrote earlier:
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
I won't repeat the previous message again, but I've run a memory tester (memtest86) and think it's unlikely the memory is at fault. And all the surface testing I've done makes it unlikely the disk is at fault.
I'm wondering if possibly there might be a subtle bug in the unmounting procedures that cause the filesystem to become unsynchronized in certain (rare) environments, leaving essential data in a cache that's wiped out on shutdown.
Hmmm. Did I miss it, or did you tell us you weren't using the append="MEM=128M" lilo boot statement?
Just curious to see if that's involved in your predicament.
I never heard of the MEM=128M statement. Is it supposed to be necessary? If so, it's another of those magical incantations. Paul Abrahams -- 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/
"Paul W. Abrahams" wrote:
Hmmm. Did I miss it, or did you tell us you weren't using the append="MEM=128M" lilo boot statement?
Just curious to see if that's involved in your predicament.
I never heard of the MEM=128M statement. Is it supposed to be necessary? If so, it's another of those magical incantations.
It shouldn't be nessesarry with a 2.2.X Kernel, but it was nessesarry for the elder non SuSE 2.0.X series. Juergen -- =========================================== __ _ Juergen Braukmann juergen.braukmann@gmx.de| -o)/ / (_)__ __ ____ __ Tel: 0201-743648 dk4jb@db0qs.#nrw.deu.eu | /\\ /__/ / _ \/ // /\ \/ / ===========================================_\_v __/_/_//_/\_,_/ /_/\_\ -- 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/
Juergen Braukmann wrote:
"Paul W. Abrahams" wrote:
Hmmm. Did I miss it, or did you tell us you weren't using the append="MEM=128M" lilo boot statement?
Just curious to see if that's involved in your predicament.
I never heard of the MEM=128M statement. Is it supposed to be necessary? If so, it's another of those magical incantations.
It shouldn't be nessesarry with a 2.2.X Kernel, but it was nessesarry for the elder non SuSE 2.0.X series.
But Danian Slavek wrote:
Yes, I have 128 megs of ram but 6.2 didn't detect all of it. I added the aforementioned MEM=128M and after that everything worked great.
Where lieth the truth? Paul Abrahams -- 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/
Juergen Braukmann wrote:
"Paul W. Abrahams" wrote:
Hmmm. Did I miss it, or did you tell us you weren't using the append="MEM=128M" lilo boot statement?
Just curious to see if that's involved in your predicament.
I never heard of the MEM=128M statement. Is it supposed to be
necessary? If
so, it's another of those magical incantations.
It shouldn't be nessesarry with a 2.2.X Kernel, but it was nessesarry for the elder non SuSE 2.0.X series.
But Danian Slavek wrote:
Yes, I have 128 megs of ram but 6.2 didn't detect all of it. I added
I thought someone on this list gave me the info on how to do it. I got the info from my local lug. free reported that I had only 64M or ram. I used yast and put in that in the append line and after that free always showed the correct amount the
aforementioned MEM=128M and after that everything worked great.
Where lieth the truth?
Paul Abrahams
-- 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/
"Paul W. Abrahams" wrote:
Juergen Braukmann wrote:
"Paul W. Abrahams" wrote:
Hmmm. Did I miss it, or did you tell us you weren't using the append="MEM=128M" lilo boot statement?
Just curious to see if that's involved in your predicament.
I never heard of the MEM=128M statement. Is it supposed to be necessary? If so, it's another of those magical incantations.
It shouldn't be nessesarry with a 2.2.X Kernel, but it was nessesarry for the elder non SuSE 2.0.X series.
But Danian Slavek wrote:
Yes, I have 128 megs of ram but 6.2 didn't detect all of it. I added the aforementioned MEM=128M and after that everything worked great.
Where lieth the truth?
That was what I wondered when I read it as well. Just checked /etc/lilo.conf: no append mem=128. Free finds my 128 MB RAM. I remember old discussions about this from the 2.0.3x days. (could be in the archives) The SuSE kernels had a patch that found the RAM correctly, stock kernels needed the append mem=... statement. I also remember that it was said that this patch was standard for 2.2.x. One should dig the archives for that, if it matters. havn't tried a homebrewed kernel for a long while, so I can't tell. With a stock kernel in use, it could still be a patch. In that case, it leaves the question why it hasn't found it's way into the standard kernel. ;-( Juergen Juergen
Paul Abrahams
-- =========================================== __ _ Juergen Braukmann juergen.braukmann@gmx.de| -o)/ / (_)__ __ ____ __ Tel: 0201-743648 dk4jb@db0qs.#nrw.deu.eu | /\\ /__/ / _ \/ // /\ \/ / ===========================================_\_v __/_/_//_/\_,_/ /_/\_\ -- 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/
Brad Shelton wrote:
On Wed, Feb 09, 2000 at 05:43:05PM -0500, Paul W. Abrahams wrote:
"Paul W. Abrahams" wrote earlier:
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
I won't repeat the previous message again, but I've run a memory tester (memtest86) and think it's unlikely the memory is at fault. And all the surface testing I've done makes it unlikely the disk is at fault.>
Hmmm. Did I miss it, or did you tell us you weren't using the append="MEM=128M" lilo boot statement?
Just curious to see if that's involved in your predicament.
Very interesting. I never would have thought to look in the Boot-Prompt Howto for something relevant to the problem, and the MEM parameter isn't even mentioned in Werner Almsberger's Lilo writeup. But according to the description in the Boot-Prompt Howto, the BIOS isn't able to report memory sizes greater than 64MB, so Linux needs to be told if more memory is present. I suspect there was some nonuniform treatment of memory access going on. As it happens, I rebuilt the kernel, and after doing that (though with the same version) the problem went away. Of course I would have liked to compare the current kernel configuration with the configuration when I was getting the error, but /usr/src/linux was in the partition that got clobbered. I'm going to start another thread on this subject to see what experiences others have had. Paul Abrahams -- 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/
Brad Shelton pointed out to me the existence of a Lilo parameter `mem=' for specifying the amount of available RAM. On further investigation I discovered a few paragraphs on this subject in the Boot-Prompt Howto (not where I would have expected it). It seems that the normal PC Bios is unable to report memory sizes greater than 64MB. Linux needs this parameter to find out how much memory is actually available. According to Linus the All-Knowing as quoted in that document, overstating the amount of available memory can cause all kinds of disasters. I suspect the problems I was having with a filesystem implosion were related to some nonuniformity in the mechanisms used by different system components for determining how much memory is present. In my case I've specified `mem=128M'. Has anyone else found this parameter to be necessary? Paul Abrahams -- 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/
On Sat, Feb 12, 2000 at 08:42:22PM -0500, Paul W. Abrahams wrote:
Brad Shelton pointed out to me the existence of a Lilo parameter `mem=' for specifying the amount of available RAM. On further investigation I discovered a few paragraphs on this subject in the Boot-Prompt Howto (not where I would have expected it).
It seems that the normal PC Bios is unable to report memory sizes greater than 64MB. Linux needs this parameter to find out how much memory is actually available. According to Linus the All-Knowing as quoted in that document, overstating the amount of available memory can cause all kinds of disasters. I suspect the problems I was having with a filesystem implosion were related to some nonuniformity in the mechanisms used by different system components for determining how much memory is present.
In my case I've specified `mem=128M'. Has anyone else found this parameter to be necessary?
Only on non-SuSE kernels trees. -- Brad Shelton On Line Exchange http://online-isp.com -- 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/
Brad Shelton wrote:
On Sat, Feb 12, 2000 at 08:42:22PM -0500, Paul W. Abrahams wrote:
Brad Shelton pointed out to me the existence of a Lilo parameter `mem=' for specifying the amount of available RAM. On further investigation I discovered a few paragraphs on this subject in the Boot-Prompt Howto (not where I would have expected it).
It seems that the normal PC Bios is unable to report memory sizes greater than 64MB. Linux needs this parameter to find out how much memory is actually available. According to Linus the All-Knowing as quoted in that document, overstating the amount of available memory can cause all kinds of disasters. I suspect the problems I was having with a filesystem implosion were related to some nonuniformity in the mechanisms used by different system components for determining how much memory is present.
In my case I've specified `mem=128M'. Has anyone else found this parameter to be necessary?
Only on non-SuSE kernels trees.
In other words, if I pick up a kernel (such as 2.2.14) that isn't provided by SuSE, I do need the parameter - right? Paul Abrahams -- 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/
In my case I've specified `mem=128M'. Has anyone else found this parameter to be necessary?
On 6.3 i haven't found this to be a problem. the free command on my system does show the right amount of ram with out adding anything to lilo. total used free shared buffers cached Mem: 127720 64472 63248 27720 5576 44108 -/+ buffers/cache: 14788 112932 Swap: 417988 0 417988 *--------------------------------* | Chris Large clarge@macn.bc.ca | | http://gone for now | *--------------------------------* -- 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/
Brad Shelton pointed out to me the existence of a Lilo parameter `mem=' for specifying the amount of available RAM. On further investigation I discovered a few paragraphs on this subject in the Boot-Prompt Howto (not where I would have expected it).
It seems that the normal PC Bios is unable to report memory sizes greater than 64MB. Linux needs this parameter to find out how much memory is actually available. According to Linus the All-Knowing as quoted in that document, overstating the amount of available memory can cause all kinds of disasters. I suspect the problems I was having with a filesystem implosion were related to some nonuniformity in the mechanisms used by different system components for determining how much memory is present.
In my case I've specified `mem=128M'. Has anyone else found this
parameter
to be necessary?
Yes, I have 128 megs of ram but 6.2 didn't detect all of it. I added the aforementioned MEM=128M and after that everything worked great.
Paul Abrahams
-- 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/
participants (11)
-
abrahams＠valinet.com -
ben＠whack.org -
bshelton＠online-isp.com -
chris.reeves＠iname.com -
clarge＠macn.bc.ca -
damianks＠netnet.net -
ethant＠earthlink.net -
juergen.braukmann＠ruhr-west.de -
nick.leroy＠norland.com -
stefan.troeger＠wirtschaft.tu-chemnitz.de -
stefano.papini＠intercai.etnoteam.it