Re: Kernel update break access to boot devices?
From: chuck (chucko_at_nil.car)
Date: 07/28/05
- Next message: Andrew Gideon: "Re: lvm and 'mkfs -c' and pvcreate"
- Previous message: eacosta_at_yahoo.com: "SCSI emulation for USB Mass Storage devices on Kernel 2.6.12 (FC4)"
- In reply to: Haines Brown: "Re: Kernel update break access to boot devices?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 27 Jul 2005 22:44:58 GMT
Haines Brown <brownh@hartford-hwp.com> wrote in
news:87mzo8nuic.fsf@teufel.hartford-hwp.com:
> Chuck, you are spotting confusion on my part, but I'm not sure about
> the alternatives you offer.
>
> As for draining CMOS, I had forgotten that BIOS Setup offers that as
> an option. Thanks for the alert that it often does a poor job at
> it. So battery removal (with power disconnected) seems to be the way
> to drain CMOS.
>
>> You're confusing ROM and RAM you can wipe the lower 2k of RAM memory
>> (BIOS) simply using debug.
>
> OK, I get the feeling that you are saying that ROM BIOS writes data to
> that part of RAM reserved for the BIOS. To remove the volatile data in
> ROM BIOS, remove the battery; to remove non-volatile data in that
> portion of RAM dedicated to the use of the BIOS, use debug.
No, you still got it wrong. I assumed you knew what the abreviations meant.
ROM stands for read-only memory which means it can't be written to (it can be
erased and then re-written in certain ways with certain types of ROM). RAM
stands for random-access memory, which is the the writtable memory a digital
computer uses.
> In my case, it looks like there's nothing wrong with the RAM itself,
> but instead it seems that ROM data from cards (video, SCSI), or from
> hard disk (MBR) is not being written to RAM correctly, is stepped on
> once written to it, or is not retrieved properly from RAM for use in
> the boot process.
no, it is rarely copied unless you shadow it (from the bios). Most likely a
power surge scrambled part of the cmos ram. If the rest of ram is scrambled
it doesn't matter so much because once the computer is turned off it is
wiped, but cmos is backed up by that battery.
> If so, I understand this data processessing is driven by the CPU,
> using data stored in ROM BIOS. So one possibility is that ROM BIOS
> data is bad. My question was, if I remove the battery to drain the
> ROM BIOS of its own data, replace the battery, enter BIOS setup, set
> the non default values I need, would that correct any data corruption
> that had existed before within ROM BIOS?
replace rom with ram and you got it right. Except for any cmos ram that the
bios doe not reset (of which there always seems to be).
> It seems that during the boot process later on, dmesg shows that my
> video and SCSI drivers load just fine, but earlier on, before the
> dmesg log begins (before my hard disks are accessed), it seems that
> the drivers in the card ROMs are not being loaded properly. In fact, I
> think I saw briefly very early on some reference to my SCSI card
> drivers not being found or loaded for the bootstrap operation.
> If the bootstrap SCSI driver (the one pulled in from the card) is not
> in RAM, it would explain why I can't boot from hard disk, but can boot
> from floppy. If the video VGA driver pulled from my graphics card is
> not quite right, it might explain why I briefly see garbage between
> the display of the motherboard banner and the access to the SCSI card
> to scan SCSI devices, and then the display of garbage after the SCSI
> scan when the hard disk boot loader should be loading and displayed.
>
> What I don't understand is that my Tcl windows under X become
> pixelatted periodically and need to be refreshed (by selection) to
> make them more readable, and text in my browser becomes so pixellated
> as to be unreadable unless refreshed, and window movement has led to a
> a browser hang or to a complete desktop hang requiring a dirty
> shutdown.
that sounds like a hardware problem with the video card.
> I don't see how this relates to the BIOS problem above except that
> their appearance coincided, for the graphics driver in use is loaded
> long after the early bootstrap operation, which uses a simple VGA
> driver from the video card's ROM.
> One thing suggested to me, is that in the power supply or on the
> motherboard there is high frequency interference resulting from a
> capacitor failure, and this interference is messing up data processing
> during the bootstrap process and, once booted. my graphical display.
> I have no idea how to address this except a) inspect motherboard for
> expanded or oozing capacitors, b) substitute another power supply. I'm
> in the process of doing both.
>
I would suggest having a computer store with A+ certified techs check your
whole motherboard ram but no cards. that should isolate your problem at the
very least
- Next message: Andrew Gideon: "Re: lvm and 'mkfs -c' and pvcreate"
- Previous message: eacosta_at_yahoo.com: "SCSI emulation for USB Mass Storage devices on Kernel 2.6.12 (FC4)"
- In reply to: Haines Brown: "Re: Kernel update break access to boot devices?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
