[LAT] 2.6.29-rt1

hollunder at gmx.at hollunder at gmx.at
Fri Mar 27 08:57:01 EDT 2009

On Thu, 26 Mar 2009 22:20:48 +0100
Robin Gareus <robin at gareus.org> wrote:

> Hash: SHA1
> Fernando Lopez-Lezcano wrote:
> > On Thu, 2009-03-26 at 19:52 +0100, Robin Gareus wrote:
> > We've got a winner! 2.6.29-rt1
> > 
> >> 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). 
> 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 (-:

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?

> >> 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
> Version: GnuPG v1.4.9 (GNU/Linux)
> iEYEARECAAYFAknL8bAACgkQeVUk8U+VK0KoCgCggXU8WvZhiy36i0NtagBy4nqw
> =B1qh

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?


More information about the Linux-audio-tuning mailing list