linux-kernel - Re: oops in ioapic_write

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]

Message-ID: <m1bp9jdvic.fsf@fess.ebiederm.org>
Date:	Tue, 03 Aug 2010 18:19:55 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Dave Airlie <airlied@...il.com>,
	Iranna D Ankad <iranna.ankad@...ibm.com>,
	Gary Hade <garyhade@...ibm.com>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Thomas Renninger <trenn@...e.de>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: oops in ioapic_write_entry

Yinghai Lu <yinghai@...nel.org> writes:

> On 08/03/2010 02:38 PM, Eric W. Biederman wrote:
>> Yinghai Lu <yinghai@...nel.org> writes:
>> 
>>> On 08/03/2010 04:08 AM, Eric W. Biederman wrote:
>>>>
>>>> For the common case I think we still do the right thing, even now, for
>>>> these broken bios tables.  There is likely an uncommon case for which
>>>> something like your shared_legacy_irq deserves to be used, especially
>>>> at it preserves our well tested historical behavior.
>>>
>>> Dave, Irnna, Gary:
>>>
>>> can you check this patch on your systems?
>>>
>>> [PATCH] x86: check if apic/pin is shared with legacy one
>>>
>>> fix system that external device that have io apic on apic0/pin(0-15)
>> 
>> Nacked-by: "Eric W. Biederman" <ebiederm@...ssion.com>
>> 
>> Your patch addresses what appears to be a theoretical issue, caused by
>> a BIOS bug.  So far you have not presented a credible scenario where
>> this would affect anything in real life except the user visible irq
>> number.
>> 
>> Will you please stop, think, and describe what is going on clearly
>> and how you expect this patch to affect anything, and please stop
>> selling this patch as the solution to all of the world's ills.  You
>> are being sloppy and wasting everyone's time.
>
> That is real problem in pin_2_irq()
>
> Nvidia chipset system with legacy bios will have problem when user try to boot with acpi is disabled.
> LinuxBIOS should be ok, already have external devices to use pin above 15.

The Nvidia chipset will have what problem?

> Also your patch does cause kernel crash when acpi is disabled in virtualbox even there
> could be BIOS problem there.
> kernel before your patch does work in that conf.

What is the kernel crash?

I believe you have told me earlier that the problems you see with 2.6.35 are
roughly, while those setups work with 2.3.34?

>  cause kernel with acpi crash in virtual box.
> 
> [    5.536000] querying PCI -> IRQ mapping bus:0, slot:11, pin:0.
> [    5.540000] ehci_hcd 0000:00:0b.0: can't find IRQ for PCI INT A; probably buggy MP table
> [
> 
> and on kvm it got:
> [    4.352280] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k6-NAPI
> [    4.356012] e1000: Copyright (c) 1999-2006 Intel Corporation.
> [    4.360120] querying PCI -> IRQ mapping bus:0, slot:3, pin:0.
> [    4.364006] PCI BIOS passed nonexistent PCI bus 0!
> [    4.368007] e1000 0000:00:03.0: can't find IRQ for PCI INT A; probably buggy MP table
> [    4.372049] e1000 0000:00:03.0: setting latency timer to 64


Can you send out boot log with "debug apic=debug pci=routeirq" for the
working 2.6.34, the failing 2.6.35, and your .config?

With a little luck that will be enough to allow us to pinpoint the
problem case.

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/