From: "Magnus Damm" <magnus.damm@gmail.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [Fastboot] [PATCH] kexec: Avoid migration of already disabled irqs (ia64)
Date: Wed, 31 Jan 2007 03:49:52 +0000 [thread overview]
Message-ID: <aec7e5c30701301949g35355525qe50f5cb50fbef9a2@mail.gmail.com> (raw)
In-Reply-To: <45C005C1.5010606@sgi.com>
On 1/31/07, Jay Lan <jlan@sgi.com> wrote:
> Magnus Damm wrote:
> > kexec: Avoid migration of already disabled irqs (ia64)
> >
> > This patch fixes up ia64 kexec support for HP rx2620 hardware. It does this
> > by skipping migration of already disabled irqs. This is most likely a problem
> > on other ia64 platforms as well, but I've only tested this on one machine
> > so far.
>
> I have not seen this problem on SN systems.
Ok, thanks. Let me give you more details.
When I perform "kexec -e" the following output appears on my serial
console (with my patch applied).
ACPI: PCI interrupt for device 0000:20:02.1 disabled
GSI 30 (level, low) -> CPU 1 (0x0200) vector 53 unregistered
ACPI: PCI interrupt for device 0000:20:02.0 disabled
GSI 29 (level, low) -> CPU 0 (0x0000) vector 52 unregistered
Starting new kernel
CPU 1 is now offline
CPU 2 is now offline
CPU 3 is now offline
Linux version 2.6.20-rc6 (damm@localhost) (gcc version 3.4.5) #1 SMP
Tue Jan 30 16:59:54 JST 2007
Without the patch the kernel tries to migrate already disabled
interrupts which results in this:
ACPI: PCI interrupt for device 0000:20:02.1 disabled
GSI 30 (level, low) -> CPU 1 (0x0200) vector 53 unregistered
ACPI: PCI interrupt for device 0000:20:02.0 disabled
GSI 29 (level, low) -> CPU 0 (0x0000) vector 52 unregistered
Starting new kernel
BUG: at arch/ia64/kernel/irq.c:155 migrate_irqs()
Call Trace:
[<a000000100012e10>] show_stack+0x50/0xa0
spà000040fb7f7b20 bspà000040fb7f0d60
[<a000000100012e90>] dump_stack+0x30/0x60
spà000040fb7f7cf0 bspà000040fb7f0d48
[<a000000100011610>] fixup_irqs+0x490/0x680
spà000040fb7f7cf0 bspà000040fb7f0d08
[<a000000100055300>] __cpu_disable+0x5c0/0x660
spà000040fb7f7d80 bspà000040fb7f0cb8
[<a0000001000d21c0>] take_cpu_down+0x20/0x80
spà000040fb7f7dc0 bspà000040fb7f0ca0
[<a0000001000dcd90>] do_stop+0x250/0x360
spà000040fb7f7dc0 bspà000040fb7f0c60
[<a0000001000bf9b0>] kthread+0x230/0x2a0
spà000040fb7f7dd0 bspà000040fb7f0c20
[<a000000100015290>] kernel_thread_helper+0xd0/0x100
spà000040fb7f7e30 bspà000040fb7f0bf0
[<a0000001000094c0>] start_kernel_thread+0x20/0x40
spà000040fb7f7e30 bspà000040fb7f0bf0
irq 53, desc: a0000001007d1080, depth: 0, count: 3, unhandled: 0
->handle_irq(): 0000000000000000, 0x0
->chip(): a000000100831fa8, no_irq_chip+0x0/0x80
->action(): 0000000000000000
IRQ_DISABLED set
Unexpected irq vector 0x35 on CPU 1!
CPU 1 is now offline
...
(more or less same thing on CPU2 and CPU3 as well)
This is how my /proc/interrupts look:
/ # cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
28: 1 1 1 1 LSAPIC cpe_poll
29: 0 0 0 0 LSAPIC cmc_poll
31: 0 0 0 0 LSAPIC cmc_hndlr
48: 0 0 0 0 IO-SAPIC-level acpi
49: 0 52 0 0 IO-SAPIC-level serial
52: 104 0 0 0 IO-SAPIC-level eth0
232: 0 0 0 0 LSAPIC mca_rdzv
238: 0 0 0 0 LSAPIC perfmon
239: 7027 6979 7055 6916 LSAPIC timer
240: 0 0 0 0 LSAPIC mca_wkup
253: 145 106 766 689 LSAPIC resched
254: 21 50 51 34 LSAPIC IPI
ERR: 0
Are IOSAPIC interrupts routed to multiples CPUs in your case?
Do you get any "ACPI: PCI interrupt for device nnn disabled" messages?
Thanks!
/ magnus
next prev parent reply other threads:[~2007-01-31 3:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-31 2:58 [Fastboot] [PATCH] kexec: Avoid migration of already disabled Jay Lan
2007-01-31 3:49 ` Magnus Damm [this message]
2007-01-31 4:54 ` [Fastboot] [PATCH] kexec: Avoid migration of already disabled irqs (ia64) Zou, Nanhai
2007-01-31 5:57 ` Magnus Damm
2007-01-31 6:07 ` Zou, Nanhai
2007-01-31 18:09 ` [Fastboot] [PATCH] kexec: Avoid migration of already disabled Jay Lan
2007-02-01 6:02 ` [Fastboot] [PATCH] kexec: Avoid migration of already disabled irqs (ia64) Magnus Damm
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=aec7e5c30701301949g35355525qe50f5cb50fbef9a2@mail.gmail.com \
--to=magnus.damm@gmail.com \
--cc=linux-ia64@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox