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 d"not 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]