From: Jason Wessel <jason.wessel@windriver.com>
To: Don Zickus <dzickus@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <peterz@infradead.org>,
Robert Richter <robert.richter@amd.com>,
ying.huang@intel.com, Andi Kleen <andi@firstfloor.org>,
LKML <linux-kernel@vger.kernel.org>,
Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [V2 PATCH 0/6] x86, NMI: give NMI handler a face-lift
Date: Fri, 12 Nov 2010 10:34:53 -0600 [thread overview]
Message-ID: <4CDD6CAD.30303@windriver.com> (raw)
In-Reply-To: <20101112161144.GP4823@redhat.com>
On 11/12/2010 10:11 AM, Don Zickus wrote:
> On Fri, Nov 12, 2010 at 09:55:53AM -0600, Jason Wessel wrote:
>
>>> To answer your question, I doubt this patch series will change that
>>> outcome if it is still broken.
>>>
>>>
>>>
>> It was most definitely broken in 2.6.36->2.6.37-rc1. Randy Dunlap had
>> pointed this out in a separate exchange that was not on LKML.
>>
>
> Can you clarify by what you mean by broken above? Was 2.6.36 good or bad?
>
>
It was absolutely broken in 2.6.36 which I believe is where the new
LOCKUP_DETECTOR changes were introduced.
I tested 2.6.35 and it does not hard hang, but suffered from a different
problem with a perf API change. The kgdb tests appear to loop and loop
emitting endless streams of output in 2.6.35 and I already have that
problem patched.
At this point we have to get back to a working base line. At this point
if you use 2.6.37-rc1 the last remaining problem is the perf + lockup
detector callback eating the injected DIE_NMI event which is meant to
enter the debugger.
>> The symptom you would see looks like:
>>
>> ...kernel boot...
>> Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
>> serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
>> 00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
>> brd: module loaded
>> kgdb: Registered I/O driver kgdbts.
>> kgdbts:RUN plant and detach test
>> [...HARD HANG STARTS HERE...]
>>
>> The kernel is looping at that point waiting for the master kgdb cpu to
>> have all the slaves join the debugger but it never happens because the
>> perf callback chain which is used by the lockup detector eats the NMI
>> IPI event. After the perf callback is processed perf returns
>> NOTIFY_STOP so the notifier which brings the slave CPU into the debugger
>> never fires.
>>
>
> Ok. We have code to handle extra spurious NMIs that is hard to accurately
> determine if the NMI was for perf or someone else. This logic may still
> need tweaking. What cpu are you running on? AMD/Intel? If Intel, then
> core/core2/nehalem?
>
>
In this case I just built a 32 bit kernel and ran it under kvm on a 64
bit host. I can send you the .config separately.
kvm -nographic -k en-us -kernel arch/x86/boot/bzImage -net user -net
nic,macaddr=52:54:00:12:34:56,model=i82557b -append
"console=ttyS0,115200 ip=dhcp root=/dev/nfs
nfsroot=10.0.2.2:/space/exp/x86 rw acpi=force UMA=1" -smp 2
Thanks,
Jason.
next prev parent reply other threads:[~2010-11-12 16:35 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-12 14:43 [V2 PATCH 0/6] x86, NMI: give NMI handler a face-lift Don Zickus
2010-11-12 14:43 ` [PATCH 1/6] x86, NMI: Add NMI symbol constants and rename memory parity to PCI SERR Don Zickus
2010-11-12 14:43 ` [PATCH 2/6] x86, NMI: Add touch_nmi_watchdog to io_check_error delay Don Zickus
2010-11-12 14:43 ` [PATCH 3/6] x86, NMI: Rewrite NMI handler Don Zickus
2010-11-12 14:43 ` [PATCH 4/6] x86, NMI: Remove DIE_NMI_IPI and add priorties to handlers Don Zickus
2010-11-12 14:43 ` [PATCH 5/6] x86, NMI: Allow NMI reason io port (0x61) to be processed on any CPU Don Zickus
2010-11-12 14:43 ` [PATCH 6/6] x86, NMI: Remove do_nmi_callback logic Don Zickus
2010-11-12 15:05 ` [V2 PATCH 0/6] x86, NMI: give NMI handler a face-lift Jason Wessel
2010-11-12 15:42 ` Don Zickus
2010-11-12 15:55 ` Jason Wessel
2010-11-12 16:11 ` Don Zickus
2010-11-12 16:34 ` Jason Wessel [this message]
2010-11-12 17:27 ` Don Zickus
2010-11-16 18:43 ` Don Zickus
2010-11-16 20:04 ` Jason Wessel
2010-11-18 8:05 ` Ingo Molnar
2010-11-18 12:47 ` Jason Wessel
2010-11-18 13:17 ` Peter Zijlstra
2010-11-18 14:32 ` Don Zickus
2010-11-18 15:18 ` Jason Wessel
2010-11-18 15:38 ` Peter Zijlstra
2010-11-18 19:32 ` Don Zickus
2010-11-18 19:51 ` Jason Wessel
2010-11-18 20:04 ` Peter Zijlstra
2010-11-18 20:08 ` Don Zickus
2010-11-18 20:11 ` Cyrill Gorcunov
2010-11-18 20:52 ` Don Zickus
2010-11-18 21:01 ` Cyrill Gorcunov
2010-11-18 21:16 ` Don Zickus
2010-11-18 21:26 ` Cyrill Gorcunov
2010-11-18 20:28 ` Cyrill Gorcunov
2010-11-18 20:39 ` Cyrill Gorcunov
2010-11-18 21:02 ` Don Zickus
2010-11-18 21:19 ` Cyrill Gorcunov
2010-11-18 20:30 ` Peter Zijlstra
2010-11-19 16:59 ` Don Zickus
2010-11-19 18:25 ` Peter Zijlstra
2010-11-19 22:59 ` Don Zickus
2010-11-19 23:09 ` Peter Zijlstra
2010-11-19 23:30 ` Jason Wessel
2010-11-22 14:22 ` Don Zickus
2010-11-22 14:22 ` Don Zickus
2010-11-22 14:29 ` Peter Zijlstra
2010-11-18 20:04 ` Cyrill Gorcunov
2010-11-18 21:56 ` Cyrill Gorcunov
2010-11-18 21:58 ` Cyrill Gorcunov
2010-11-18 22:15 ` Cyrill Gorcunov
2010-11-18 22:24 ` Jason Wessel
2010-11-18 22:27 ` Cyrill Gorcunov
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=4CDD6CAD.30303@windriver.com \
--to=jason.wessel@windriver.com \
--cc=andi@firstfloor.org \
--cc=dzickus@redhat.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=robert.richter@amd.com \
--cc=ying.huang@intel.com \
/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.