x86/sfi: fix ioapic gsi range
in [Kernel]
|
Prev: Fwd: EXT3 File System Corruption 2.6.34
Next: 2.6.35-rc2-git1 - include/linux/cgroup.h:534 invoked rcu_dereference_check() without protection!
From: H. Peter Anvin on 8 Jun 2010 16:40 On 06/08/2010 12:41 PM, Eric W. Biederman wrote: > > At the ioapic and gsi level, and in your firmware interface reusing the > numbers is fine. > > The issue is what acpi calls bus 0 irqs, and how drivers deal with > them. We wind up having well know irqs: irqs 3 and 4 for serial ports, > irq 7 for parallel ports. irqs 14, and 15 for ide. > > A bunch of these hardware devices we can get if someone connects up a > lpc superio chip. > > Even if sfi is never implemented on a platform where that kind of > hardware exists, the current sfi code is setup to coexist > simultaneously in the kernel with all of the infrastructure of other > platforms where those kinds of devices exist. Which means there can > be drivers compiled into your kernel that make assumptions about special > properties of the irqs 0-15. > > I have seen a lot of weird hard to track issues, because of a conflict in > assumptions over the ISA irqs. It is easiest and safest just to let the > first 16 linux irq numbers be reserved for the legacy oddness, so code can > make assumptions and we don't have to worry about it. > > As for the question about using legacy_pic to detect the absence of an irq > controller that Peter raised. We can't do that because it should be possible > for an acpi system with all of the legacy hardware to exist without needing > to implement an i8259, or ever run in the historical interrupt delivery mode > of pcs. > > With the current code you should get all of the remapping of the gsi's out > of the legacy irq space without needing to lift a finger, and if someone later > decides we need an irq override so we can have an isa irq present on a weird > embedded system on a chip the code will be able to handle that easily. > OK, let me ask this, then: if we do that, and we hardcode this as 16 magic IRQs indefinitely, does that mean we lose 16 IDT entries indefinitely as well? We are already shy on interrupt vectors, and that would make me unhappy. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: jacob pan on 8 Jun 2010 16:50 On Tue, 08 Jun 2010 12:41:45 -0700 ebiederm(a)xmission.com (Eric W. Biederman) wrote: > Even if sfi is never implemented on a platform where that kind of > hardware exists, the current sfi code is setup to coexist > simultaneously in the kernel with all of the infrastructure of other > platforms where those kinds of devices exist. Which means there can > be drivers compiled into your kernel that make assumptions about > special properties of the irqs 0-15. > SFI code can be compiled in with ACPI at the same time but at runtime there is only one used, ACPI take precedence. So there wouldn't be any additional conflict caused by SFI added APIC tables. > As for the question about using legacy_pic to detect the absence of > an irq controller that Peter raised. We can't do that because it > should be possible for an acpi system with all of the legacy hardware > to exist without needing to implement an i8259, or ever run in the > historical interrupt delivery mode of pcs. In your case, I don't understand how would it change the calculation of irq mapping. Even if you don't use i8259 on a x86 PC platform, you still have NR_LEGACY_IRQS=legacy_pic->nr_legacy_irqs. On the other side, use NR_LEGACY_IRQS breaks the existing code for Moorestown in terms of irq-gsi lookup and nr_irqs_gsi. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Yuhong Bao on 8 Jun 2010 17:00 > IRQ 14/15 is wrong for ATA today as its AHCI based on modern boxes Not to mention even before that there was native mode IDE!In fact, XP SP1 and later support switching to native mode IDE on BIOSes supporting it as described in this document:http://www.microsoft.com/whdc/device/storage/Native-modeATA.mspx Yuhong Bao _________________________________________________________________ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 8 Jun 2010 17:10 On 06/08/2010 01:59 PM, Eric W. Biederman wrote: > > No. There is no reason to loose 16 IDT entries indefinitely. We may > need a boot time allocation when we see we have isa irqs, to replace > the static allocation that we have. But for the most part we dynamically > idt entries aka vector numbers today, and there is no reason we can't > generalize that in the future. > Well, that boot time allocation is one of the things legacy_pic->nr_legacy_irq is used for, and it really makes sense, I think. I would really like to move away from a compile-time allocation, and I still find it hard to believe it has a reason to exist. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 8 Jun 2010 17:10
"H. Peter Anvin" <hpa(a)zytor.com> writes: > On 06/08/2010 12:41 PM, Eric W. Biederman wrote: >> >> At the ioapic and gsi level, and in your firmware interface reusing the >> numbers is fine. >> >> The issue is what acpi calls bus 0 irqs, and how drivers deal with >> them. We wind up having well know irqs: irqs 3 and 4 for serial ports, >> irq 7 for parallel ports. irqs 14, and 15 for ide. >> >> A bunch of these hardware devices we can get if someone connects up a >> lpc superio chip. >> >> Even if sfi is never implemented on a platform where that kind of >> hardware exists, the current sfi code is setup to coexist >> simultaneously in the kernel with all of the infrastructure of other >> platforms where those kinds of devices exist. Which means there can >> be drivers compiled into your kernel that make assumptions about special >> properties of the irqs 0-15. >> >> I have seen a lot of weird hard to track issues, because of a conflict in >> assumptions over the ISA irqs. It is easiest and safest just to let the >> first 16 linux irq numbers be reserved for the legacy oddness, so code can >> make assumptions and we don't have to worry about it. >> >> As for the question about using legacy_pic to detect the absence of an irq >> controller that Peter raised. We can't do that because it should be possible >> for an acpi system with all of the legacy hardware to exist without needing >> to implement an i8259, or ever run in the historical interrupt delivery mode >> of pcs. >> >> With the current code you should get all of the remapping of the gsi's out >> of the legacy irq space without needing to lift a finger, and if someone later >> decides we need an irq override so we can have an isa irq present on a weird >> embedded system on a chip the code will be able to handle that easily. >> > > OK, let me ask this, then: if we do that, and we hardcode this as 16 > magic IRQs indefinitely, does that mean we lose 16 IDT entries > indefinitely as well? We are already shy on interrupt vectors, and that > would make me unhappy. No. There is no reason to loose 16 IDT entries indefinitely. We may need a boot time allocation when we see we have isa irqs, to replace the static allocation that we have. But for the most part we dynamically idt entries aka vector numbers today, and there is no reason we can't generalize that in the future. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |