27 Mar
2009
27 Mar
'09
9:57 a.m.
On Thu, 26 Mar 2009 22:20:48 +0100
Robin Gareus <robin(a)gareus.org> wrote:
I do have lockups with any kernel and I'm
reasonably certain that it's
a hardware failure, probably the mainboard and something related to
graphics. Is there a way to check if it's only X that locked completely
or if it's the whole machine?
Philipp
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fernando Lopez-Lezcano wrote:
I had that shutdown problem at first as well (with 2.6.29-rc8-rt4),
simply because I had all power saving options disabled. Then I
built 2.6.26-rt1 and I had changed it, but it didn't power off and
after checking the config file it turned out that the changes weren't
there. Compiled again today and it works now.
Basically I just enabled acpi, but only a rather minimal set
(CONFIG_ACPI_BUTTON=y, CONFIG_ACPI_FAN=y) but I guess you know that
kind of stuff far better than me. But maybe there's some weirdness with
your config as well?
On Thu, 2009-03-26 at 19:52 +0100, Robin Gareus
wrote:
We've got a winner! 2.6.29-rt1
This is related to your BIOS or motherboard. Do you have the same
problem with a vanilla 2.6.29?
Since I only did reboots, I just performed a shutdown to check and it
powers off just fine. I don't use any boot options (only "root=xx
quiet ro") on this dual-core intel.
Why shut-down, anyway? s2ram and s2disk work fine with 2.6.29-rt1. I'm
very very happy (-: Hmmmm, getting close but not yet a winner :-)
> I've been tracking the 2.6.29 rcx series and I'm still having some
> problems. 2.6.29-rt1 still does not shutdown correctly with my
> kernel configuration options (you need to specify "noreplace-smp"
> in the kernel startup line for shutdown to happen - otherwise you
> get a problem at the very end of the halt and the machine does not
> power down). > And I have
seen it hung (hard) the whole machine where a normal
> kernel would just work. I'm still trying to find a way to debug
> that.
I did not have those for a long time (~2years), previously I
experienced hard lockups when using wifi (iwl3945) and rtirq.
I dare say there's no way to debug that - but you should ask that on
rt-linux list. There's ways to tweak things
in /proc/sys/kernel/sched_* if this lock-up is caused by a runaway
process.
It could also be CPU overheating, but then the problem should also
occur with non realtime kernels as well.
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAknL8bAACgkQeVUk8U+VK0KoCgCggXU8WvZhiy36i0NtagBy4nqw
lroAoKHWWMBmZP9w5VUY+WJXY1rNs5BM
=B1qh
-----END PGP SIGNATURE-----