Re: [SLUG] Kernel Panix

From: Mark (mark@bish.net)
Date: Sat Jul 21 2001 - 19:05:59 EDT


You sure these are matched sticks?

Like one stick being ECC and the others not being ECC?

On Fri, 20 Jul 2001, Bill wrote:

> On Saturday 21 July 2001 13:20, you wrote:
> > Try taking the RAM out and re-installing it.
> > Ed.
> >
> > Russell Hires wrote:
> > > Well, you went way overboard on reistalling and the whole bit. If you
> > > just installed new RAM and your kernel panics, then take out the new
> > > RAM... If that doesn't work, ask around first...
>
> There are 15 possible combinations (that I have found) of installing either
> 1,2 or all 3 sticks of ram in the 3 slots provided for it. I graphed out
> matrices to try to ensure I didn't miss any possibilities.
>
> In each case, the bios recognizes the proper ram count.
>
> In each case, a single stick causes Linux to GPF almost immediately with
> attendent hex dump.
>
> In each case, 2 or more sticks causes Linux to get part way through the
> hardware check.
>
> Scroll lock doesn't work to stop the messages so I only get FAST glimpses of
> the ram count under Linux. I can't be certain if it is recognizing it or not.
> Following the RAID check (RAID ... what RAID? I gots no RAID ... only two
> HD's with no mirroring, striping or anything else fancy going on.) I get the
> original error messages.
>
> > > > "Invalid session number or type of track"
> > > >
> > > > "Kernel Panic: VFS: Unable to mount root fs on 03:05"
>
> Is this, perhaps, a failing of kernel 2.2.17? During each install I manually
> provided the ram count as "1536M" after Linux had automatically located only
> 896M. The install program choked when I tried entering "1.5 G" but seemed
> content with the "1536M" formatting. This included starting the install
> process with "F1 / linux mem=1536".
>
> Reinserting the previous single 128M stick causes the same hex dump as I got
> with the single 512M sticks.
>
> I have used a pencil eraser to remove the (very minor) oxidation on the ram
> edge contacts of the new ram. Because I have seen a number of chips work just
> fine with much greater levels of oxidation, I really don't think it was a
> factor. Moreover, rubbing it off didn't change the outcome. The past couple
> of days have been very humid (lower static potential) and I am also pretty
> religious about grounding myself / wearing non-synthetic clothing when
> handling electronic components that retail for $100 / ounce. :-)
>
> Because the bios can detect these sticks in any order of insertion and any
> combination and because Linux gives me the same error message with any single
> stick ... even if it is the old (known good) memory ... and because it errors
> out at different points in the boot process depending on how many sticks are
> inserted (and thus can be shown to be actually using the ram -in any 2-3
> stick combination- up to the point of error) I am forced to conclude that I
> was shipped good ram and that the problem lays within Linux.
>
> So, I'd like to solicit additional suggestions if I might. My hunch is that I
> am not setting LILO up correctly ... possibly mis-specifying the quantity of
> ram. Additionally, I am not getting offered a choice between LILO and GRUB
> ... only between LILO and NO BOOTLOADER. This seems odd.
>
> Bill
>

------------------------------------------------------------------------
| Mark Bishop (mark@bish.net) | Computer Engineer |
| 813.258.2390 | Network Engineer |
| http://bish.net | Embedded Programmer |



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 16:28:44 EDT