linux-kernel - Re: 2.6.19-rc1 genirq causes either boot hang or "do

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 07 Oct 2006 10:52:24 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Muli Ben-Yehuda <muli@...ibm.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Rajesh Shah <rajesh.shah@...el.com>, Andi Kleen <ak@....de>,
	"Protasevich, Natalie" <Natalie.Protasevich@...SYS.com>,
	"Luck, Tony" <tony.luck@...el.com>, Andrew Morton <akpm@...l.org>,
	Linus Torvalds <torvalds@...l.org>,
	Linux-Kernel <linux-kernel@...r.kernel.org>,
	Badari Pulavarty <pbadari@...il.com>
Subject: Re: 2.6.19-rc1 genirq causes either boot hang or "do_IRQ: cannot handle IRQ -1"

Muli Ben-Yehuda <muli@...ibm.com> writes:

> On Fri, Oct 06, 2006 at 05:42:40PM -0600, Eric W. Biederman wrote:
>
>> If I read your bootlog right. You have logical cpus, but only two
>> sockets, and I think only two cores.  The other two logical cpus
>> being hyperthreaded.
>
> Yes, 2 sockets each of which is HT. Here's a /proc/cpuinfo from a
> distro kernel:

Ok.  From looking at an individual case the ioapic is programmed
correctly and I don't see a reason the local apic would be programmed
incorrectly.  However logical delivery mode and lowest priority
delivery mode are enabled.  So we are asking the interrupt delivery
subsystem to choose a cpu to deliver the interrupt to and then are not
giving the cpu any choice.  So we may be confusing things. 

Can you try CONFIG_CPU_HOTPLUG?  That will force genapic to be set
to genapic_physflat instead of genapic_flat.

I am hoping that by running the apics in a different delivery mode
that explicitly says just deliver this interrupt to this cpu we
will avoid the problem you are seeing.

If genapic_physflat works we will have to decide what to do about
genapic_flat.

Thanks,

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/