Re: sdram and linux
tony mollica wrote: Hi. Just looking for a little more info. Just installed 64megs 168 pin sdram (replacing the 64megs of the usual type 72 pin edo stuff) in my system and it appears to be causing file system corruption, as indicated on boot up by fsck (attempted boot up, actually). Booting from the rescue disk and running fsck reports lots of problems, fixes them all, but the problems reappear at the next reboot from the hard disk drive. Also ran into a problem with programs exiting unexpectedly and core dumping for no apparent reason. What kind of motherboard? Were the EDO dimms 5 Volt? Some motherboards will allow mixing or switching, but sometimes it is not so easy. Most SDRAM is 3.3 Volt, unbuffered. Some might not be. Make sure... Also, most SDRAM (especially PC100 stuff coming soon) has Serial Presence Detect(SPD) on it, so that when the POST code in BIOS is initializing hardware, it can properly configure memory timings and such based on the fact that SDRAM is different than EDO. It is possible to detect the difference between the two using old memory sizing techniques, but SPD is more accurate... if it is accurate! If your BIOS is not recognizing the SDRAM as SDRAM for some reason, you will not see stable behavior at all. Has there been any similar reports or other problems using 168 pin sdram type memory or are there any hardware or kernel settings that I may have overlooked to make this work? The memory works ok on 'other' o.s.'s and machines. Does the memory work okay in your machine with, say, DOS? I know, it sucks, but it is less demanding, so to speak. We have found in our testing at work that 16-bit and 32-bit other OS's from Redmond work okay most of the time with a particular memory config, but if you try to run the multitasking version (the one with the NT in it), you see a lot of blue screen. We Crash... Anyway, I would say that you should check motherboard/chipset requirements (3.3 or 5 volts-- important distinction, probably unbuffered), check that the BIOS knows how to configure SDRAM, and make sure the stuff works in some minimum config (like DOS). Simply booting and passing the BIOS memory test is not always enough. Finally, if you plan on upgrading to a 100MHz motherboard some time in the near future, get GOOD SDRAM. PC100 is fairly challenging. I have been spending a lot of time lately dealing with SDRAM on intel motherboards, so I got a little wordy. Hope it helps somebody... -dh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sdram and linux
thanks for the info. The motherboard recognizes the memory as sdram just fine and linux starts up ok but then the problems start. Mostly, applications stop and disappear from the desktop without warning and the file system (as fsck reports) becomes corrupted. The machine never locked up and it appears to shut down normally, but on the next boot, fsck lists some problems that require that I boot from a floppy and run fsck on hda(1). fsck then fixes all the problems (several screens worth) and then linux will boot up normally again, shutdown ok and then the next boot up begins with the problems all over again. I've done this sequence about 8 times without any apparent permanent damage. No applications or programs appear to be corrupted by this sequence. I re-installed the original 72 pin EDO stuff and have been running both the 2.0.33 and 2.0.30 kernels I built without any problems at all. I've come to the conclusion that the no-name motherboard I'm using, which has been working just fine and without even a burp, just has a problem with sdram. One 64 meg sdram I tried showed as 16 megs AND locked up on boot. The second one registered the mem ok, but had the previous problems. Both work ok on the Redmond stuff. This motherboard doesn't appear to have any bios configuration items in it for the sdram. thanks, -- tony mollica [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
sdram and linux
Hi. Just looking for a little more info. Just installed 64megs 168 pin sdram (replacing the 64megs of the usual type 72 pin edo stuff) in my system and it appears to be causing file system corruption, as indicated on boot up by fsck (attempted boot up, actually). Booting from the rescue disk and running fsck reports lots of problems, fixes them all, but the problems reappear at the next reboot from the hard disk drive. Also ran into a problem with programs exiting unexpectedly and core dumping for no apparent reason. Tried my Debian kernels 2.0.30 and 2.0.33 with the same result and put the original memory back, which seems to have fixed the problem with either kernel version. Has there been any similar reports or other problems using 168 pin sdram type memory or are there any hardware or kernel settings that I may have overlooked to make this work? The memory works ok on 'other' o.s.'s and machines. thanks, -- tony mollica [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sdram and linux
Hi, This may also be indicative of incipient problems with your hard drive. Back up all your data (just in case) ... manoj -- Our business is run on trust. We trust you will pay in advance. Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sdram and linux
I've got 128MB of ECC SDRAM in my hamm box and haven't had any problems. Some people say that you should only use SDRAM that is certified to work with your motherboard. Did you set up your BIOS to use SDRAM instead of DRAM? -Ossama __ Ossama Othman [EMAIL PROTECTED] --- PGP Keys --- Public: http://astrosun.tn.cornell.edu/staff/othman/OO_PUBLIC.asc REVOKED: http://astrosun.tn.cornell.edu/staff/othman/OO_REVOKED.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sdram and linux
tony mollica wrote: Hi. Just looking for a little more info. Just installed 64megs 168 pin sdram (replacing the 64megs of the usual type 72 pin edo stuff) in my system and it appears to be causing file system corruption, as indicated on boot up by fsck (attempted boot up, actually). Booting from the rescue disk and running fsck reports lots of problems, fixes them all, but the problems reappear at the next reboot from the hard disk drive. Also ran into a problem with programs exiting unexpectedly and core dumping for no apparent reason. Tried my Debian kernels 2.0.30 and 2.0.33 with the same result and put the original memory back, which seems to have fixed the problem with either kernel version. Has there been any similar reports or other problems using 168 pin sdram type memory or are there any hardware or kernel settings that I may have overlooked to make this work? The memory works ok on 'other' o.s.'s and machines. thanks, -- tony mollica [EMAIL PROTECTED] It may be possible that you SDRAM is damaged. You usually won't notice this on other OS's, because there is a big difference in the RAM-usage. Linux really 'uses' the memory more than on those other 'OS's'. In fact the usage is heavy compared to other OS's. But as Manoj stated - backup your HD - just in case... ;-) Mac -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sdram and linux
can you give a little more information? I recently had a simmilar problem that munged my system ...but... it wasn't ram related (tho my RAM did go bad too..for unrelated reasons) Are you runnin gbo or hamm? There is a package that was in hamm when it was unsatble...which is on my hamm CD that I burned last month (while it was still unstable..about 3 weeks before the freeze started ) I accidently installed a package (whose name I forget)...it changed the sysvinit to use a differnt method...with a config file unfortunatly it was not unmounting filesystems when going down for reboot, it would juts kill all processes and reboot without ever umounting / and remounting read only! I noticed the problem after a reboot (I was in the middelk of troubleshooting some soundcard probrlems that required reboots) and started to debug the shutdown scripts (it took 3-4 rebpoots before i reaLized that the standard symlinks were not even being used!) before I had the problem fixed...all of these reboots and unmounting inproperly munged my system my advice: do this less /etc/init.d/rc and look at the large description at the begining...if it says something about running from a config file an dnot using sym links ...then I woul dsubmit that that is you rproblem also... get hwtools package and try memtest86...someone on debian-devel suggested that to me and it picked out my bad ram quickly thoise are my recomendations...if you are runnin gbo however... I doubt that offending package is in bo (coul dbe tho...im too lazy to look) and I dunno about hwtools but...hwtolls shouldn't really care whether it is bo or hamm... anyway memtest86 boots on its own anyway... quick Q: does memtest86 work on SDRAM ? I know it doesn't work on ECC or Parity ram? I will dfind out tonight...I am trowing 64 MB od SDRAM in my machine (nice upgrade from 32 MB of old SIMMs) -Steve tony mollica wrote: Hi. Just looking for a little more info. Just installed 64megs 168 pin sdram (replacing the 64megs of the usual type 72 pin edo stuff) in my system and it appears to be causing file system corruption, as indicated on boot up by fsck (attempted boot up, actually). Booting from the rescue disk and running fsck reports lots of problems, fixes them all, but the problems reappear at the next reboot from the hard disk drive. Also ran into a problem with programs exiting unexpectedly and core dumping for no apparent reason. Tried my Debian kernels 2.0.30 and 2.0.33 with the same result and put the original memory back, which seems to have fixed the problem with either kernel version. Has there been any similar reports or other problems using 168 pin sdram type memory or are there any hardware or kernel settings that I may have overlooked to make this work? The memory works ok on 'other' o.s.'s and machines. thanks, -- tony mollica [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sdram and linux
tony mollica writes: Hi. Just looking for a little more info. Just installed 64megs 168 pin sdram (replacing the 64megs of the usual type 72 pin edo stuff) in my system and it appears to be causing file system corruption, as indicated on boot up by fsck (attempted boot up, actually). Booting from the rescue disk and running fsck reports lots of problems, fixes them all, but the problems reappear at the next reboot from the hard disk drive. Also ran into a problem with programs exiting unexpectedly and core dumping for no apparent reason. Tried my Debian kernels 2.0.30 and 2.0.33 with the same result and put the original memory back, which seems to have fixed the problem with either kernel version. Has there been any similar reports or other problems using 168 pin sdram type memory or are there any hardware or kernel settings that I may have overlooked to make this work? The memory works ok on 'other' o.s.'s and machines. Did you check the BIOS settings and make sure the BIOS is setup for SDRAM? The typical access time of SDRAM is 10 ns, whereas EDO access time is typically 60 ns. You may have a timing problem. Remember, Linux is very demanding when it comes to hardware. -- -= Sent by Debian 1.3 Linux =- Thomas Kocourek KD4CIK @[EMAIL PROTECTED]@westgac3.dragon.com Remove @_@ for correct Email address --... ...-- ... -.. . -.- -.. - -.-. .. -.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sdram and linux
It sounds a lot like memory that is not fast enough (or not enough wait states). It might also be some sort of addressing error that does not show up in Win. Also, did you tell lilo that you have more than 64M of memory? -- best, -bill [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] from a 1996 Micro$loth ad campaign: The less you know about computers the more you want Micro$oft! See! They do get some things right! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sdram and linux
On Mon, 30 Mar 1998, Stephen Carpenter wrote: anyway memtest86 boots on its own anyway... quick Q: does memtest86 work on SDRAM ? I know it doesn't work on ECC or Parity ram? I will dfind out tonight...I am trowing 64 MB od SDRAM in my machine (nice upgrade from 32 MB of old SIMMs) Well, I've had a few problems when I installed some new sdram on my computer, too. memtest86 didnt saw them, but i had a few wierd problems, programs segfaulting and all. Apparently part of the reason was that some memory access patterns can't be reproduced with just the CPU : you may also have some other chips accessing memory, and the problems may happen only when the different accesses happen in some particular order. Thus, your memory will only fail if you have, say, a disk access and a network access at the same time as a compile. The way I tested my bad sdram was to use this script : tar czf linux.tar.gz linux mv linux linux.orig for i in 0 1 2 3 4 5 6 7 8 9 do for j in 0 1 2 3 4 5 6 7 8 9 do for k in 0 1 2 3 4 5 6 7 8 9 do echo $i$j$k tar xzf linux.tar.gz diff -U 2 -rN linux.orig linux rm -fr linux done done done mv linux.orig linux I had one of them running on each of my disks (1 IDE with triton busmatering, 1 SCSI). Then I compiled kernels in the background. I had both some sig11 problems, and some differences output by the diff in the script (btw, there was a strange pattern in these differences). problem went away when I exchanged my sdram at the store. They said it wasnt the reason, and that their sdram was okay, but I know this wasnt true. I guess they must have sold my faulty sdram to some win95 user who wont see the difference anyway - he'll just get a few more crashes than average... Michel Walken LESPINASSE - Student at Ecole Centrale Paris (France) www email : [EMAIL PROTECTED] (o o)www : http://www.via.ecp.fr/~walken/ --oOO--(_)--OOo-- C0 9B E8 D8 44 43 D3 63 5A B4 BA 55 57 5B 19 6D Just say know finger [EMAIL PROTECTED] for complete PGP key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
sdram and linux #2
Thanks for all the replies. I can appreciate the possibility of the hdd going bad, but it has been operating flawlessly before and after trying to use the sdram, but that doesn't exclude the possibility. Tried the old mem and both the .30 and .33 kernels this morning with absolutely no problems. I don't find any specific settings for the sdram in the system bios and what there is of a handbook for this generic motherboard (430vx)isn't much. The #1 suspect, I think, is an incompatibility with the m-board and, #2 would be a bad chip. I'll try a different type of sdram or use it in a win95 box. What's a few extra crashes, I don't use it very often, anyway. thanks, -- tony mollica [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
