On Fri, Jul 20, 2001 at 05:42:18PM +0000, Bill wrote:
>
> 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.
_rock!_ :-)
>
> 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.
Make sure you aren't still specifying mem=1536m without the full
amount in there. It will die horribly if it thinks it has more than
it really does.
try reinstalling the know good 128mb stick, then telling it mem=128m
and see if it still dies at VFS.
>
> 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"
ugh. the 'session number' and 'type of track' sound like
multi-session iso9660 cdrom jargon... are you sure the cdrom is not
booting my mistake or that suddenly your root= is not pointing to the
cdrom drive?
> > > >
> > > > "Kernel Panic: VFS: Unable to mount root fs on 03:05"
>
Something is not right with the hard drive. either the root fs is not
specified in properly in lilo, the scsi (maybe?) driver module is not
loading (do you need initrd to preload the module?) properly.
> 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.
try with mem=128m if you haven't yet.
>
> 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. :-)
check freshmeat for memtest86 and see if you can load it on a floppy.
it will find the minorest of quirks with ram. takes a while
sometimes, but it is worth it.
it is a good thing to have around!
>
> 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
>
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 16:29:18 EDT