lkml.org 
[lkml]   [2010]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: oops in ioapic_write_entry
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.

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.

Yinghai


\
 
 \ /
  Last update: 2010-08-04 02:41    [W:0.520 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site