You're sending replies only to me - let's keep it on the list for the benefit of others as well. Thanks! :)
On Wed, Apr 26, 2006 at 11:20:59AM -0700, Eric Poulsen wrote:
- Use factory BIOS, re-save CMOS, Boot OS, Reboot later using LB
- Use factory BIOS, NOT re-save CMOS, Boot OS, Reboot later using LB
- Use factory BIOS, re-save CMOS, powerdown, boot use LB
- Use factory BIOS, NOT re-save CMOS, powerdown, boot use LB
- Other ?
"re-save CMOS" means entering BIOS menu and choosing "save changes and exit"
When I have the crash problem, I have been using option #3. I'm not sure if that answers your question =)
Sorry, no. But the question was badly stated as well. :) More below.
I immediately flipped back to LB, and it worked as expected.
Worked reliably or did not crash while you were looking?
The crash _always_ occurs during initial kernel execution, before 'init' starts.
Depending on what the problem is, the system could crash later on as well, just that it hasn't been left running long enough or with such loads that the problem appears.
Can you reliably reproduce the crash? If not there's no way to tell if the problem has been fixed or merely isn't manifesting itself at that particular point in time.
Does just rebooting with LinuxBIOS produce different results than factory(resetCMOS)->LinuxBIOS?
Rebooting with LB crashes every time, until I reset the CMOS with the Factory BIOS. This is why I think it might be a CMOS issue -- the crashing seems stateful.
Ok! So the only successful way to boot LinuxBIOS under any circumstances is to first boot factory BIOS, have it do something (possibly rewrite CMOS, possibly something else) and then reboot into LinuxBIOS without powering off the system?
If it works also when powering off between factory BIOS and LinuxBIOS, please leave the system powered off several hours up to a day and see it that works too.
I second Richard on running memtest86, RAM problems can cause all sorts of funny things.
I'll hit the ram test ASAP. I've had other weird issues, such as the kernel taking a REALLY LONG time to initialize stuff. This is new RAM, so hopefully still under warranty.
Since this is code setting up the DRAM controller the RAM test also serves as a code test.
Any system that requires special data to be in CMOS or anywhere else and does not validate this data before using it is broken.
If by "system" you mean the BIOS, then I agree.
Any system. Development 101 has to be "validate the input!"
//Peter