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
Peter Stuge wrote:
You're sending replies only to me - let's keep it on the list for the benefit of others as well. Thanks! :)
I'm trying -- the lack of a "reply-to" header for the list is really weird.
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?
Not at all. After the "reset," I can power down and restart (this is typical because I just hit the power switch, and linux shuts down). Often, I can come back later and it boots fine. Then, it suddenly starts having issues, and this is persistent until the "reset." It _seems_ (but I haven't verified) to be exacerbated by having the machine off for a few hours/days.
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.
Haha I hadn't read this paragraph when I wrote the above. It seems that long off times screws up LB.
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!"
True.
//Peter
* Eric Poulsen eric@zyxod.com [060426 20:50]:
Peter Stuge wrote:
You're sending replies only to me - let's keep it on the list for the benefit of others as well. Thanks! :)
I'm trying -- the lack of a "reply-to" header for the list is really weird.
Most mailers have a "reply to group" or "reply to all" function that would do the right thing.
There are many reasons not to introduce or override the Reply-To: header. One is that some posters depend on their own Reply-To: settings to convey their valid return address. Another is that modifying Reply-To: makes it much more difficult to send private replies. See `Reply-To' Munging Considered Harmful [http://www.unicom.com/pw/reply-to-harmful.html] for a general discussion of this issue.
Stefan
Richard Smith wrote:
Haha I hadn't read this paragraph when I wrote the above. It seems that long off times screws up LB.
What happens if you use the clear CMOS jumper bettween boots so you always start with a zeroed CMOS?
-- Richard A. Smith
I'll give it a shot.
On Wed, Apr 26, 2006 at 11:50:24AM -0700, Eric Poulsen wrote:
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?
Not at all. After the "reset," I can power down and restart (this is typical because I just hit the power switch, and linux shuts down). Often, I can come back later and it boots fine. Then, it suddenly starts having issues, and this is persistent until the "reset."
Ok, thanks for making that clear. Can you provide some timeframes? Ie. how much later "later" means, and how much time passes between "later" and "suddenly" ? :)
It _seems_ (but I haven't verified) to be exacerbated by having the machine off for a few hours/days.
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.
Haha I hadn't read this paragraph when I wrote the above. It seems that long off times screws up LB.
The reason this may matter is that special configuration of chips performed by the factory BIOS may well stay around in chip registers even if power is cut for some time, while if the special config is in CMOS it will of course survive without power a lot longer.
//Peter
-
Eric Poulsen -
Peter Stuge -
Richard Smith -
Stefan Reinauer