From: ebiederm@xmission.com (Eric W. Biederman)
To: Yinghai Lu <yinghai@kernel.org>
Cc: Dave Airlie <airlied@gmail.com>,
Iranna D Ankad <iranna.ankad@in.ibm.com>,
Gary Hade <garyhade@us.ibm.com>,
LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
Thomas Renninger <trenn@suse.de>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: oops in ioapic_write_entry
Date: Tue, 03 Aug 2010 18:19:55 -0700 [thread overview]
Message-ID: <m1bp9jdvic.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <4C58ADB2.8060702@kernel.org> (Yinghai Lu's message of "Tue\, 03 Aug 2010 17\:00\:50 -0700")
Yinghai Lu <yinghai@kernel.org> writes:
> On 08/03/2010 02:38 PM, Eric W. Biederman wrote:
>> Yinghai Lu <yinghai@kernel.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@xmission.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
next prev parent reply other threads:[~2010-08-04 1:20 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-02 5:28 oops in ioapic_write_entry Dave Airlie
2010-08-02 6:49 ` Yinghai Lu
2010-08-02 23:17 ` Dave Airlie
2010-08-03 1:32 ` Yinghai Lu
2010-08-03 1:34 ` Yinghai Lu
2010-08-03 3:13 ` Eric W. Biederman
2010-08-03 7:19 ` Yinghai Lu
2010-08-03 8:00 ` Eric W. Biederman
2010-08-03 8:04 ` Yinghai Lu
2010-08-03 8:56 ` Eric W. Biederman
2010-08-03 9:01 ` Yinghai Lu
2010-08-03 9:15 ` Eric W. Biederman
2010-08-03 9:36 ` Yinghai Lu
2010-08-03 11:08 ` Eric W. Biederman
2010-08-03 19:45 ` Yinghai Lu
2010-08-03 20:02 ` Yinghai Lu
2010-08-03 21:38 ` Eric W. Biederman
2010-08-03 23:12 ` Dave Airlie
2010-08-04 0:00 ` Yinghai Lu
2010-08-04 1:19 ` Eric W. Biederman [this message]
2010-08-04 7:33 ` Ingo Molnar
2010-08-04 8:59 ` Yinghai Lu
2010-08-04 9:26 ` Ingo Molnar
2010-08-04 12:12 ` Eric W. Biederman
2010-08-04 19:22 ` Yinghai Lu
2010-08-04 20:34 ` Eric W. Biederman
2010-08-04 22:06 ` Yinghai Lu
2010-08-03 8:00 ` Yinghai Lu
2010-08-03 8:27 ` Eric W. Biederman
2010-08-03 3:26 ` Eric W. Biederman
[not found] ` <AANLkTi=qtLkY0=h77=EVL+y1q41b_cMBODvL4Hu6A6wL@mail.gmail.com>
2010-08-03 6:00 ` Eric W. Biederman
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=m1bp9jdvic.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=airlied@gmail.com \
--cc=garyhade@us.ibm.com \
--cc=hpa@zytor.com \
--cc=iranna.ankad@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=trenn@suse.de \
--cc=yinghai@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 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.