From: Rui Nuno Capela <rncbc@rncbc.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org,
Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
Gregory Haskins <ghaskins@novell.com>
Subject: Re: 2.6.23-rt4 (was 2.6.23-rt1 trouble)
Date: Sat, 27 Oct 2007 21:06:15 +0100 [thread overview]
Message-ID: <47239A37.8000401@rncbc.org> (raw)
In-Reply-To: <Pine.LNX.4.58.0710271203170.28617@gandalf.stny.rr.com>
Steven Rostedt wrote:
> --
>
> On Sat, 27 Oct 2007, Rui Nuno Capela wrote:
>
>>> On Mon, October 15, 2007 11:49, Rui Nuno Capela wrote:
>>>> I am experiencing some highly annoying but intermitent freezing on a
>>>> pentium4 2.80G HT/SMT box, when doing normal desktop work with 2.6.23-rt1.
>>>>
>>>>
>>>> The same crippling behavior does not occur on a Core 2 Due T7200 2.0G
>>>> SMP, so I suspect it's something due specific to the SMT scheduling
>>>> support (Hyper-Threading). But can't tell for sure, obviously :)
>>>>
>>> I was wrong. After several trials the same behavior also occurs on the
>>> Core2 Duo T7200. It just took longer to show its nasty.
>>>
>>>
>>>> The symptoms are noticeable primarily as some X/GUI intermitent freezing,
>>>> sometimes only one application, then several and ultimately the whole X
>>>> desktop becomes completely unresponsive. It looks like scheduling
>
> When things start to freeze, could you capture the output of a sysrq-t.
>
yes, you can find a complete serial console capture here, where it holds
the final SysRq-T output:
http://www.rncbc.org/datahub/console-2.6.23.1-rt4.1-1.log
the corresponding .config is also there:
http://www.rncbc.org/datahub/config-2.6.23.1-rt4.1
the reason this is a new kernel build, following a shot in the dark from
nick mainsbridge, which let out the ntfs module build (CONFIG_NTFS_FS is
not set) suggesting that would mitigate similar freezes.
in deed the general feel is that it seems to run longer and less prone
to those incidents, but that is just a gut feeling, nothing more.
hope this be any useful.
>
>>>> problems. There is this hint that switching to a spare console terminal
>>>> (via Ctrl+Alt+Fn) might cause later recovery. But its just a question of
>>>> some more time for it just happens again and again, one after another,
>>>> several applications becoming temporarily frozen and just by luck the
>>>> system gets back to normal, probably due to some incidental shake-up :)
>>>> but there are other times that nothing seems to help with no alternative
>>>> to the power-reset switch.
>>>>
>>>> I could not find any evidence on dmesg or in the system logs, of any
>>>> apparent trouble. No BUGs, no oops, no panics, no nothing. It just
>>>> freezes, this and that, now and then. It just makes it all unworkable
>>>> and obviously subject to ditching.
>>>>
>>>> Again, this only happens on this P4/HT box. On a Core2 Duo laptop, with
>>>> same 2.6.23-rt1 with the very same kernel configuration, it does not show
>>>> any illness and is running quite fine.
>>>>
>>> False. It used to run fine, until the creeps happen first time :(
>>>
>>>
>>>> Remember one report I had about a similar freezing behavior? Now it's
>>>> happening the other way around: the core2 is OK, the pentium4 is KO.
>>>>
>>> Now it applies to all 2.6.23-rt1 images I could test upon.
>>>
>>>
>>>> One naive suspicion goes like the new rcu-preempt code is to blame, since
>>>> I don't remember having this or any other trouble with 2.6.23-rc8-rt1.
>>>>
>>> Not be sure anymore, but this seems to be still a valid assumption.
>>>
>> just to let you know that still the same trouble persists with 2.6.23.1-rt4
>>
>> .config can be found here:
>> http://www.rncbc.org/datahub/config-2.6.23.1-rt4.0
>>
>
> I have a P4HT laptop (unfortunately with no serial). I use it as one of my
> main machines, so it will suck for me when it freezes ;-). I'll take your
> config and try it out.
>
> I'll most likely do this on Monday since process Wife has the highest
> priority over the weekend ;-)
>
that is also true here :)
otoh, as reported before, the freezes are not exclusive to P4HT, which
is the main box I'm been reporting here (the one which has a good old
serial port anyway), but also applies to my other laptop, an core2 duo
t7200.
bye
--
rncbc aka Rui Nuno Capela
rncbc@rncbc.org
next prev parent reply other threads:[~2007-10-27 20:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-12 2:04 2.6.23-rt1 Steven Rostedt
2007-10-15 10:49 ` 2.6.23-rt1 trouble Rui Nuno Capela
2007-10-17 17:39 ` Rui Nuno Capela
2007-10-27 14:43 ` 2.6.23-rt4 (was 2.6.23-rt1 trouble) Rui Nuno Capela
2007-10-27 16:05 ` Steven Rostedt
2007-10-27 20:06 ` Rui Nuno Capela [this message]
2007-10-30 19:11 ` 2.6.23.1-rt5 " Rui Nuno Capela
2007-10-30 19:28 ` Steven Rostedt
2007-10-30 19:54 ` Rui Nuno Capela
2007-10-30 20:06 ` Steven Rostedt
2007-10-30 21:02 ` Rui Nuno Capela
2007-10-31 8:02 ` Alessio Igor Bogani
2007-11-03 18:22 ` Gabriel C
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47239A37.8000401@rncbc.org \
--to=rncbc@rncbc.org \
--cc=ghaskins@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.