dyn_array/nr_irqs/sparse_irq support v10
A message that is not in the archive (sent off-list or not yet received): [email protected]
(lkml Cc:-ed)
Quoted 11 lines · Yinghai Lu
v10: make the x86 32 bit support
sparse_irqtoo.
also make remove irqbalance in kernel for 32 bit
and make 32 bit supportper_cpuvector. so start merging orio_apic_xx.c01-03 is some fix for current tree
04: is revert for one patch hide in sched/ and tip/masterbased on tip/master
to do:
mergeio_apic_xx.c
ok, i've created a new tip/irq/sparseirq topic branch for this.
Could you please send future updates against:
git-checkout tip/master
git-merge tip/irq/sparseirq
Not yet integrated into tip/master, i've still got some other backlog.
A couple of observations about the general structure of the sparse irqs code:
- the new APIs should probably live in mm/bootmem.c not in init/main.c, and in bootmem.h. Also, it should be outlined clearly why this new API is needed as a wrapper ontop of existing bootmem mechanisms.
- the #ifdef complications, while fine for migration, should be eliminated. Could we introduce some compatible form for the definition/allocation APIs that work even if an architecture still uses a flat irq array? That would remove most of the uglinesses.
- some of the irq < 16 checks in x86 look a bit ugly, can we do anything about them?
- i think as a final-ish commit we should just remove the dyn-array define and make all architectures use this facility. You converted most of them - how many are still missing? Sparse-irq is more intrusive so that should probably stay a Kconfig knob.
- there was one aspect of NR_IRQS that was nice and useful: it acted as a sanity check against BIOS bugs and driver bugs that pass in some irrealistically high irq number. Now we'll just try to allocate some really high IRQ and accept it. I _think_ there should be a single, simple 'absolute maximum IRQ number' define which should set the maximum possible IRQ number. Lets call it NR_IRQS_MAX or so, and set it to NR_CPUS*NR_IO_APICS*224 or so?
- i'm a bit worried about linecount increase in general:
247 files changed, 3671 insertions(+), 2052 deletions(-)
could we work on reducing that somewhat? The new infrastructure bits in mm/* and kernel/irq/* will be unavoidable, what we should concentrate on is to make usage of the new facility just as straightforward, easy and compact as the old irq_desc[] usages.
A worst-case example is drivers/char/random.c: the CONFIG_HAVE_SPARSE_IRQ and CONFIG_HAVE_DYN_ARRAY #ifdef jungle is not acceptable. I think the best way out is to convert the whole kernel to the new facilities (as safely as possible, without breaking other architectures), and making sure that the end result is easy to understand and intuitive.
so i dont mind the current code as long as the extra complications are temporary during a safe conversion - but we should work on eliminating all those complications before thinking about upstream merging.
Ingo
-------------------->
the irq/sparseirq git tree can be picked up from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git irq/sparseirq
[ note, the diffstat has x86/core and some other topics that your
patches had dependencies on. Patch not included as vger would choke on its 700K size. ]
------------------>
Alan Cox (1):
serial, 8250: remove NR_IRQ usage
Alexander van Heukelum (1):
x86, 64-bit, dwarf2: push pushes 8 bytes and popf pops 8
Andreas Herrmann (2):
x86: pda_init(): fix memory leak when using CPU hotplug
x86: cpu_init(): fix memory leak when using CPU hotplug
Cyrill Gorcunov (3):
x86: apic unification - merge down lapic_get_maxlvt
x86: apic unification - merge down enable_NMI_through_LVT0
x86: apic interrupts - move assignments to irqinit_32.c, v2
David Brownell (2):
hpet: /dev/hpet - fixes and cleanup
hpet: /dev/hpet - fixes and cleanup, fix
Eric W. Biederman (1):
genirq: enable polling for disabled screaming irqs
Hiroshi Shimamoto (1):
x86_32: use apic_ops at print_local_APIC()
Huang Weiyi (1):
arch/x86/kernel/genx2apic_uv_x.c: Removed duplicated include
Ingo Molnar (2):
x86, xen: fix apic_ops build on UP
x86, lguest: fix apic_ops build on UP
Jaswinder Singh (27):
x86: Introducing asm/syscalls.h
x86: process_32.c declare cpu_number before they get used
x86: signal_XX.c declare do_notify_resume before they get used
x86: time_XX.c declare functions before they get used
x86: setup.c declare saved_video_mode before they get used
x86: e820.c declare pci_mem_start before they get used
x86: pci-dma.c declare iommu_bio_merge before they get used
x86: pci-nommu.c declare nommu_dma_ops before they get used
x86: i387.c declare dump_fpu() before they get used
x86: ptrace.c declare functions before they get used
x86: proc.c declare cpuinfo_op before they get used
x86: common.c declare idle_regs before they get used
x86: mtrr/main.c declare range_state as static
x86: apic_XX.c declare functions before they get used
x86: vm86_32.c declare functions before they get used
x86: mm/init_XX.c declare functions before they get used
x86: mm/fault.c declare do_page_fault before they get used
x86: mm/ioremap.c declare early_ioremap_debug and early_ioremap_nested as static
x86: mm/pageattr.c declare arch_report_meminfo before they get used
x86: mm/pgtable_32.c declare set_pmd_pfn before they get used
x86: mach-default/setup.c declare no_broadcast before they get used
x86_64: Declare new_utsname in asm-x86/syscalls.h
X86_32: declare pt_regs_access as unsigned long
X86_SMP: smp.c declare functions before they get used
X86_SMP: smpboot.c declare idle_thread_array and smp_b_stepping as static
X86_SMP: ipi.c declare functions before they get used
X86_SMP: tlb_XX.c declare smp_invalidate_interrupt before they get used
Joe Buehler (1):
x86: add PCI ID for 6300ESB force hpet
Kevin Hao (1):
x86: get irq for hpet timer
Krzysztof Oledzki (1):
x86: add another PCI ID for ICH6 force-hpet
Maciej W. Rozycki (1):
x86: PIC, L-APIC and I/O APIC debug information
Randy Dunlap (1):
documentation: move hpet.txt to timers/ subdirectory
Suresh Siddha (36):
x64, x2apic/intr-remap: Intel vt-d, IOMMU code reorganization
x64, x2apic/intr-remap: fix the need for sequential array allocation of iommus x64, x2apic/intr-remap: code re-structuring, to be used by both DMA and Interrupt remapping x64, x2apic/intr-remap: use CONFIG_DMAR for DMA-remapping specific code
x64, x2apic/intr-remap: Fix the need for RMRR in the DMA-remapping detection
x64, x2apic/intr-remap: parse ioapic scope under vt-d structures
x64, x2apic/intr-remap: move IOMMU_WAIT_OP() macro to intel-iommu.h
x64, x2apic/intr-remap: Queued invalidation infrastructure (part of VT-d)
x64, x2apic/intr-remap: Interrupt remapping infrastructure
x64, x2apic/intr-remap: routines managing Interrupt remapping table entries.
x64, x2apic/intr-remap: generic irq migration support from process context
x64, x2apic/intr-remap: 8259 specific mask/unmask routines
x64, x2apic/intr-remap: ioapic routines which deal with initial io-apic RTE setup x64, x2apic/intr-remap: introduce read_apic_id() to genapic routines
x64, x2apic/intr-remap: Interrupt-remapping and x2apic support, fix
x64, x2apic/intr-remap: basic apic ops support
x64, x2apic/intr-remap: cpuid bits for x2apic feature
x64, x2apic/intr-remap: disable DMA-remapping if Interrupt-remapping is detected (temporary quirk) x64, x2apic/intr-remap: x2apic ops for x2apic mode support
x64, x2apic/intr-remap: introcude self IPI to genapic routines
x64, x2apic/intr-remap: x2apic cluster mode support
x64, x2apic/intr-remap: setup init_apic_ldr for UV
x64, x2apic/intr-remap: IO-APIC support for interrupt-remapping
x64, x2apic/intr-remap: MSI and MSI-X support for interrupt remapping infrastructure x64, x2apic/intr-remap: add x2apic support, including enabling interrupt-remapping x64, x2apic/intr-remap: support for x2apic physical mode support
x64, x2apic/intr-remap: introduce CONFIG_INTR_REMAP
x64, x2apic/intr-remap: Interrupt-remapping and x2apic support
x2apic: uninline uv_init_apic_ldr()
x2apic: xen64 paravirt basic apic ops
x2apic: kernel-parameter documentation for "x2apic_phys"
x86: let 32bit use apic_ops too - fix
x86: apic_ops for lguest
x86: APIC: Remove apic_write_around(); use alternatives, merge fix
x64, apic: use generic apic_write() for ack_APIC_irq()
x64, fpu: fix possible FPU leakage in error conditions
Thomas Gleixner (1):
genirq: remove last NO_IDLE_HZ leftovers
Vegard Nossum (3):
x86: fix spurious '#' in kvm header
x86: consolidate header guards
x86: consolidate header guards
Yinghai Lu (62):
x86: let 32bit use apic_ops too
x86: mach_apicdef.h need to include before smp.h
x86: make read_apic_id return final apicid
x86: make 64bit have get_apic_id
x86: let 32bit use apic_ops too - fix
x86: add apic probe for genapic 64bit, v2
x86: move declaring x2apic_extra_bits
x86: add setup_ioapic_ids for numaq in x86_quirks
x86: mach-bigsmp to bigsmp
x86: mach_es7000 to es7000
x86: mach_summit to summit
x86: mach-numaq to numaq
x86: add apic probe for genapic 64bit - fix
x86: print per_cpu data address
x86: add after_bootmem flag for 32bit
x86: remove irq_vectors_limits
generic: add dyn_array support
add per_cpu_dyn_array support
x86: alloc dyn_array all together
x86: enable dyn_array support
irq: introduce nr_irqs
x86: use nr_irqs
drivers/char: use nr_irqs
drivers/net: use nr_irqs
drivers/pci/ intr remapping: use nr_irqs
drivers/pcmcia: use nr_irqs
drivers/rtc: use nr_irqs
drivers/scsi: use nr_irqs
drivers/serial: use nr_irqs
fs/proc: use nr_irqs
drivers/xen: use nr_irqs
irqs: make irq_timer_state to use dyn_array
irq: make irq2_iommu to use dyn_array
irq: make irq_desc to use dyn_array
irq: make irqs in kernel stat use per_cpu_dyn_array
x86: use dyn_array in io_apic_xx.c
x86, irq: get nr_irqs from madt
x86: remove nr_irq_vectors
generic: sparse irqs: use irq_desc() together with dyn_array, instead of irq_desc[]
x86: add irq_cfg in io_apic_64.c
x86: put irq_2_pin pointer into irq_cfg
x86: put timer_rand_state pointer into irq_desc
x86: move kstat_irqs from kstat to irq_desc
irq: add irq_desc_without_new
irq: replace loop with nr_irqs with for_each_irq_desc
irq, fs/proc: replace loop with nr_irqs for proc/stat
x86, ioapic: replace loop with nr_irqs with for_each_irq_icfg
irq: remove >= nr_irqs checking with config_have_sparse_irq
generic: add irq_desc in function in paramater
x86: check with without_new in show_interrupts
x86_64: rename irq_desc/irq_desc_with_new
irq: separate irq_descX from irq_descX_free
x86_64: separate irq_cfgx from irq_cfgx_free
x86_64: make /proc/interrupts work with dyn irq_desc
x86: put irq_2_iommu pointer into irq_desc
x86: use 28 bits irq NR for pci msi/msix and ht
x86: remove irqbalance in kernel for 32 bit
x86: add irq_cfg for 32bit
x86: make 32bit use irq_cfg_with_new, etc
x86: make 32bit to use irq_2_pin in irq_cfg
x86: make 32 bit to use sparse_irq
x86: make 32bit support per_cpu vector
Documentation/00-INDEX | 2 -
Documentation/kernel-parameters.txt | 6 +
Documentation/timers/00-INDEX | 10 +
Documentation/{ => timers}/hpet.txt | 43 +-
arch/Kconfig | 6 +
arch/alpha/kernel/irq.c | 23 +-
arch/alpha/kernel/irq_alpha.c | 7 +-
arch/alpha/kernel/irq_i8259.c | 8 +-
arch/alpha/kernel/irq_pyxis.c | 9 +-
arch/alpha/kernel/irq_srm.c | 9 +-
arch/alpha/kernel/sys_alcor.c | 9 +-
arch/alpha/kernel/sys_cabriolet.c | 8 +-
arch/alpha/kernel/sys_dp264.c | 9 +-
arch/alpha/kernel/sys_eb64p.c | 8 +-
arch/alpha/kernel/sys_eiger.c | 7 +-
arch/alpha/kernel/sys_jensen.c | 50 +-
arch/alpha/kernel/sys_marvel.c | 20 +-
arch/alpha/kernel/sys_mikasa.c | 8 +-
arch/alpha/kernel/sys_noritake.c | 8 +-
arch/alpha/kernel/sys_rawhide.c | 8 +-
arch/alpha/kernel/sys_rx164.c | 8 +-
arch/alpha/kernel/sys_sable.c | 8 +-
arch/alpha/kernel/sys_takara.c | 8 +-
arch/alpha/kernel/sys_titan.c | 8 +-
arch/alpha/kernel/sys_wildfire.c | 19 +-
arch/arm/common/gic.c | 2 +-
arch/arm/common/it8152.c | 2 +-
arch/arm/common/locomo.c | 16 +-
arch/arm/common/sa1111.c | 4 +-
arch/arm/kernel/ecard.c | 4 +-
arch/arm/kernel/irq.c | 20 +-
arch/arm/mach-at91/gpio.c | 4 +-
arch/arm/mach-davinci/gpio.c | 13 +-
arch/arm/mach-ep93xx/core.c | 12 +-
arch/arm/mach-footbridge/isa-irq.c | 2 +-
arch/arm/mach-h720x/common.c | 2 +-
arch/arm/mach-h720x/cpu-h7202.c | 2 +-
arch/arm/mach-imx/irq.c | 2 +-
arch/arm/mach-integrator/integrator_cp.c | 2 +-
arch/arm/mach-iop13xx/msi.c | 6 +-
arch/arm/mach-ixp2000/core.c | 4 +-
arch/arm/mach-ixp2000/ixdp2x00.c | 2 +-
arch/arm/mach-ixp2000/ixdp2x01.c | 2 +-
arch/arm/mach-ixp23xx/core.c | 2 +-
arch/arm/mach-ixp23xx/ixdp2351.c | 4 +-
arch/arm/mach-lh7a40x/common.h | 2 +-
arch/arm/mach-netx/generic.c | 2 +-
arch/arm/mach-ns9xxx/board-a9m9750dev.c | 2 +-
arch/arm/mach-ns9xxx/irq.c | 3 +-
arch/arm/mach-omap1/fpga.c | 2 +-
arch/arm/mach-orion5x/irq.c | 12 +-
arch/arm/mach-pxa/gpio.c | 2 +-
arch/arm/mach-pxa/lpd270.c | 2 +-
arch/arm/mach-pxa/lubbock.c | 2 +-
arch/arm/mach-pxa/mainstone.c | 2 +-
arch/arm/mach-pxa/pcm990-baseboard.c | 2 +-
arch/arm/mach-s3c2410/bast-irq.c | 6 +-
arch/arm/mach-s3c2412/irq.c | 4 +-
arch/arm/mach-s3c2440/irq.c | 4 +-
arch/arm/mach-s3c2443/irq.c | 4 +-
arch/arm/mach-sa1100/h3600.c | 14 +-
arch/arm/mach-sa1100/irq.c | 2 +-
arch/arm/mach-sa1100/neponset.c | 6 +-
arch/arm/mach-versatile/core.c | 2 +-
arch/arm/oprofile/op_model_mpcore.c | 2 +-
arch/arm/plat-mxc/gpio.c | 7 +-
arch/arm/plat-omap/gpio.c | 12 +-
arch/arm/plat-orion/irq.c | 2 +-
arch/arm/plat-s3c24xx/irq.c | 14 +-
arch/arm/plat-s3c24xx/s3c244x-irq.c | 4 +-
arch/avr32/kernel/irq.c | 12 +-
arch/avr32/mach-at32ap/extint.c | 7 +-
arch/avr32/mach-at32ap/intc.c | 2 +-
arch/avr32/mach-at32ap/pio.c | 2 +-
arch/blackfin/kernel/irqchip.c | 12 +-
arch/blackfin/kernel/traps.c | 8 +-
arch/blackfin/mach-bf527/boards/cm_bf527.c | 2 +-
arch/blackfin/mach-bf527/boards/ezkit.c | 2 +-
arch/blackfin/mach-bf533/boards/cm_bf533.c | 2 +-
arch/blackfin/mach-bf533/boards/ezkit.c | 2 +-
arch/blackfin/mach-bf533/boards/stamp.c | 2 +-
arch/blackfin/mach-bf537/boards/cm_bf537.c | 2 +-
arch/blackfin/mach-bf537/boards/generic_board.c | 2 +-
arch/blackfin/mach-bf537/boards/stamp.c | 2 +-
arch/blackfin/mach-bf561/boards/cm_bf561.c | 2 +-
arch/blackfin/mach-bf561/boards/ezkit.c | 2 +-
arch/blackfin/mach-common/ints-priority.c | 8 +-
arch/cris/arch-v10/kernel/irq.c | 2 +-
arch/cris/arch-v32/kernel/irq.c | 6 +-
arch/cris/kernel/irq.c | 14 +-
arch/frv/kernel/irq.c | 12 +-
arch/h8300/kernel/irq.c | 26 +-
arch/ia64/hp/sim/hpsim_irq.c | 2 +-
arch/ia64/include/asm/hw_irq.h | 2 +-
arch/ia64/kernel/iosapic.c | 27 +-
arch/ia64/kernel/irq.c | 18 +-
arch/ia64/kernel/irq_ia64.c | 14 +-
arch/ia64/kernel/mca.c | 2 +-
arch/ia64/kernel/msi_ia64.c | 6 +-
arch/ia64/kernel/smpboot.c | 2 +-
arch/ia64/sn/kernel/irq.c | 11 +-
arch/ia64/sn/kernel/msi_sn.c | 6 +-
arch/m32r/kernel/irq.c | 14 +-
arch/m32r/platforms/m32104ut/setup.c | 37 +-
arch/m32r/platforms/m32700ut/setup.c | 133 ++-
arch/m32r/platforms/mappi/setup.c | 84 +-
arch/m32r/platforms/mappi2/setup.c | 103 +-
arch/m32r/platforms/mappi3/setup.c | 103 +-
arch/m32r/platforms/oaks32r/setup.c | 62 +-
arch/m32r/platforms/opsput/setup.c | 149 ++-
arch/m32r/platforms/usrv/setup.c | 92 +-
arch/m68k/kernel/ints.c | 2 +
arch/m68knommu/kernel/irq.c | 18 +-
arch/mips/au1000/common/irq.c | 2 +-
arch/mips/dec/ioasic-irq.c | 2 +-
arch/mips/emma2rh/markeins/irq_markeins.c | 2 +-
arch/mips/kernel/irq-gic.c | 2 +-
arch/mips/kernel/irq-msc01.c | 2 +-
arch/mips/kernel/irq.c | 12 +-
arch/mips/kernel/smtc.c | 2 +-
arch/mips/mti-malta/malta-smtc.c | 2 +-
arch/mips/sgi-ip22/ip22-int.c | 2 +-
arch/mips/sgi-ip22/ip22-time.c | 2 +-
arch/mips/sgi-ip32/ip32-irq.c | 10 +-
arch/mips/sibyte/bcm1480/irq.c | 5 +-
arch/mips/sibyte/bcm1480/smp.c | 2 +-
arch/mips/sibyte/sb1250/irq.c | 5 +-
arch/mips/sibyte/sb1250/smp.c | 2 +-
arch/mips/sni/a20r.c | 2 +-
arch/mips/sni/pcimt.c | 2 +-
arch/mips/sni/pcit.c | 2 +-
arch/mips/sni/rm200.c | 2 +-
arch/mips/vr41xx/common/icu.c | 44 +-
arch/mips/vr41xx/common/irq.c | 2 +-
arch/mn10300/kernel/irq.c | 14 +-
arch/parisc/kernel/irq.c | 45 +-
arch/powerpc/include/asm/irq.h | 2 +-
arch/powerpc/kernel/crash.c | 2 +-
arch/powerpc/kernel/irq.c | 17 +-
arch/powerpc/platforms/8xx/m8xx_setup.c | 2 +-
arch/powerpc/platforms/cell/interrupt.c | 2 +-
arch/powerpc/platforms/powermac/pic.c | 4 +-
arch/powerpc/platforms/pseries/eeh_driver.c | 2 +-
arch/powerpc/platforms/pseries/xics.c | 4 +-
arch/powerpc/sysdev/cpm2_pic.c | 5 +-
arch/powerpc/sysdev/mpic.c | 16 +-
arch/powerpc/sysdev/qe_lib/qe_ic.c | 2 +-
arch/s390/kernel/irq.c | 2 +
arch/sh/boards/mach-cayman/irq.c | 4 +-
arch/sh/boards/mach-dreamcast/irq.c | 2 +-
arch/sh/boards/mach-dreamcast/setup.c | 2 +-
arch/sh/boards/mach-microdev/irq.c | 4 +-
arch/sh/boards/mach-se/7206/irq.c | 2 +-
arch/sh/boards/mach-se/7343/irq.c | 2 +-
arch/sh/boards/mach-se/7722/irq.c | 2 +-
arch/sh/boards/mach-systemh/irq.c | 4 +-
arch/sh/cchips/hd6446x/hd64461.c | 4 +-
arch/sh/cchips/hd6446x/hd64465/setup.c | 4 +-
arch/sh/kernel/cpu/irq/imask.c | 4 +-
arch/sh/kernel/cpu/irq/intc-sh5.c | 4 +-
arch/sh/kernel/irq.c | 14 +-
arch/sparc/kernel/irq.c | 3 +
arch/sparc64/kernel/irq.c | 45 +-
arch/sparc64/kernel/pci_msi.c | 2 +-
arch/sparc64/kernel/time.c | 3 +-
arch/um/kernel/irq.c | 33 +-
arch/x86/Kconfig | 18 +-
arch/x86/boot/compressed/misc.c | 2 +-
arch/x86/configs/i386_defconfig | 1 -
arch/x86/{mach-es7000 => es7000}/Makefile | 0
arch/x86/{mach-es7000 => es7000}/es7000.h | 18 +-
arch/x86/{mach-es7000 => es7000}/es7000plat.c | 2 +-
arch/x86/kernel/Makefile | 2 +
arch/x86/kernel/acpi/boot.c | 34 +-
arch/x86/kernel/apic_32.c | 105 +-
arch/x86/kernel/apic_64.c | 251 ++++-
arch/x86/kernel/asm-offsets_64.c | 2 +-
arch/x86/kernel/cpu/common_64.c | 40 +-
arch/x86/kernel/cpu/feature_names.c | 2 +-
arch/x86/kernel/cpu/mtrr/main.c | 2 +-
arch/x86/kernel/entry_32.S | 2 +-
arch/x86/kernel/entry_64.S | 4 +-
arch/x86/kernel/genapic_64.c | 88 +-
arch/x86/kernel/genapic_flat_64.c | 62 +-
arch/x86/kernel/genx2apic_cluster.c | 164 +++
arch/x86/kernel/genx2apic_phys.c | 159 +++
arch/x86/kernel/genx2apic_uv_x.c | 70 +-
arch/x86/kernel/hpet.c | 6 +-
arch/x86/kernel/i8259.c | 24 +
arch/x86/kernel/io_apic_32.c | 1346 +++++++++++---------
arch/x86/kernel/io_apic_64.c | 1163 +++++++++++++++---
arch/x86/kernel/ioport.c | 1 +
arch/x86/kernel/ipi.c | 3 +-
arch/x86/kernel/irq_32.c | 71 +-
arch/x86/kernel/irq_64.c | 74 +-
arch/x86/kernel/irqinit_32.c | 85 ++-
arch/x86/kernel/irqinit_64.c | 28 +-
arch/x86/kernel/ldt.c | 1 +
arch/x86/kernel/mpparse.c | 2 +
arch/x86/kernel/numaq_32.c | 7 +
arch/x86/kernel/paravirt.c | 2 -
arch/x86/kernel/process_32.c | 2 +
arch/x86/kernel/process_64.c | 1 +
arch/x86/kernel/ptrace.c | 2 +-
arch/x86/kernel/quirks.c | 3 -
arch/x86/kernel/setup.c | 8 +
arch/x86/kernel/setup_percpu.c | 28 +-
arch/x86/kernel/signal_32.c | 1 +
arch/x86/kernel/signal_64.c | 12 +-
arch/x86/kernel/smpboot.c | 42 +-
arch/x86/kernel/summit_32.c | 2 +-
arch/x86/kernel/sys_i386_32.c | 2 +
arch/x86/kernel/sys_x86_64.c | 1 +
arch/x86/kernel/syscall_64.c | 4 +-
arch/x86/kernel/time_32.c | 1 +
arch/x86/kernel/tls.c | 1 +
arch/x86/kernel/traps_64.c | 9 +-
arch/x86/kernel/visws_quirks.c | 32 +-
arch/x86/kernel/vm86_32.c | 1 +
arch/x86/kernel/vmi_32.c | 4 +-
arch/x86/kernel/vmlinux_32.lds.S | 1 +
arch/x86/kernel/vmlinux_64.lds.S | 3 +
arch/x86/lguest/boot.c | 40 +-
arch/x86/mach-default/setup.c | 19 +-
arch/x86/mach-generic/Makefile | 2 +-
arch/x86/mach-generic/bigsmp.c | 13 +-
arch/x86/mach-generic/es7000.c | 27 +-
arch/x86/mach-generic/numaq.c | 26 +-
arch/x86/mach-generic/summit.c | 25 +-
arch/x86/mach-voyager/voyager_smp.c | 4 +-
arch/x86/mm/fault.c | 3 +-
arch/x86/mm/init_32.c | 4 +
arch/x86/mm/ioremap.c | 4 +-
arch/x86/pci/acpi.c | 5 -
arch/x86/xen/enlighten.c | 45 +-
arch/xtensa/kernel/irq.c | 14 +-
drivers/char/hpet.c | 155 ++-
drivers/char/random.c | 72 +-
drivers/char/vr41xx_giu.c | 2 +-
drivers/gpio/gpiolib.c | 2 +-
drivers/mfd/asic3.c | 4 +-
drivers/mfd/htc-egpio.c | 2 +-
drivers/mfd/tc6393xb.c | 3 +-
drivers/net/3c59x.c | 4 +-
drivers/net/hamradio/baycom_ser_fdx.c | 4 +-
drivers/net/hamradio/scc.c | 6 +-
drivers/net/wan/sbni.c | 2 +-
drivers/parisc/dino.c | 9 +-
drivers/parisc/eisa.c | 8 +-
drivers/parisc/gsc.c | 15 +-
drivers/parisc/iosapic.c | 4 +-
drivers/parisc/superio.c | 8 +-
drivers/pci/Makefile | 2 +
drivers/pci/dma_remapping.h | 157 +++
drivers/pci/dmar.c | 397 ++++++-
drivers/pci/htirq.c | 20 +-
drivers/pci/intel-iommu.c | 164 +--
drivers/pci/intel-iommu.h | 233 ++--
drivers/pci/intr_remapping.c | 596 +++++++++
drivers/pci/intr_remapping.h | 8 +
drivers/pcmcia/at91_cf.c | 2 +-
drivers/pcmcia/hd64465_ss.c | 12 +-
drivers/pcmcia/vrc4171_card.c | 2 +-
drivers/rtc/rtc-vr41xx.c | 4 +-
drivers/scsi/aha152x.c | 2 +-
drivers/serial/68328serial.c | 11 +-
drivers/serial/8250.c | 69 +-
drivers/serial/amba-pl010.c | 2 +-
drivers/serial/amba-pl011.c | 2 +-
drivers/serial/cpm_uart/cpm_uart_core.c | 2 +-
drivers/serial/m32r_sio.c | 4 +-
drivers/serial/serial_core.c | 2 +-
drivers/serial/serial_lh7a40x.c | 2 +-
drivers/serial/sh-sci.c | 2 +-
drivers/serial/ucc_uart.c | 2 +-
drivers/xen/events.c | 20 +-
fs/proc/proc_misc.c | 72 +-
include/asm-generic/vmlinux.lds.h | 13 +
include/asm-mips/irq.h | 2 +-
include/asm-x86/a.out-core.h | 6 +-
include/asm-x86/a.out.h | 6 +-
include/asm-x86/acpi.h | 6 +-
include/asm-x86/agp.h | 6 +-
include/asm-x86/alternative.h | 6 +-
include/asm-x86/amd_iommu.h | 6 +-
include/asm-x86/amd_iommu_types.h | 6 +-
include/asm-x86/apic.h | 76 +-
include/asm-x86/apicdef.h | 9 +-
include/asm-x86/arch_hooks.h | 8 +-
include/asm-x86/asm.h | 6 +-
include/asm-x86/atomic_32.h | 6 +-
include/asm-x86/atomic_64.h | 6 +-
include/asm-x86/auxvec.h | 6 +-
.../{mach-bigsmp/mach_apic.h => bigsmp/apic.h} | 4 +-
.../mach_apicdef.h => bigsmp/apicdef.h} | 6 +-
.../{mach-bigsmp/mach_ipi.h => bigsmp/ipi.h} | 0
include/asm-x86/bios_ebda.h | 6 +-
include/asm-x86/bitops.h | 6 +-
include/asm-x86/boot.h | 6 +-
include/asm-x86/bootparam.h | 6 +-
include/asm-x86/bug.h | 6 +-
include/asm-x86/bugs.h | 6 +-
include/asm-x86/byteorder.h | 6 +-
include/asm-x86/cache.h | 6 +-
include/asm-x86/cacheflush.h | 6 +-
include/asm-x86/calgary.h | 6 +-
include/asm-x86/checksum_32.h | 6 +-
include/asm-x86/checksum_64.h | 6 +-
include/asm-x86/cmpxchg_32.h | 6 +-
include/asm-x86/cmpxchg_64.h | 6 +-
include/asm-x86/compat.h | 6 +-
include/asm-x86/cpu.h | 6 +-
include/asm-x86/cpufeature.h | 8 +-
include/asm-x86/current.h | 6 +-
include/asm-x86/debugreg.h | 6 +-
include/asm-x86/delay.h | 6 +-
include/asm-x86/desc.h | 6 +-
include/asm-x86/desc_defs.h | 6 +-
include/asm-x86/device.h | 6 +-
include/asm-x86/div64.h | 6 +-
include/asm-x86/dma-mapping.h | 6 +-
include/asm-x86/dma.h | 6 +-
include/asm-x86/dmi.h | 6 +-
include/asm-x86/ds.h | 6 +-
include/asm-x86/dwarf2.h | 6 +-
include/asm-x86/e820.h | 7 +-
include/asm-x86/edac.h | 6 +-
include/asm-x86/efi.h | 6 +-
include/asm-x86/elf.h | 6 +-
include/asm-x86/emergency-restart.h | 6 +-
.../{mach-es7000/mach_apic.h => es7000/apic.h} | 32 +-
include/asm-x86/es7000/apicdef.h | 13 +
.../{mach-es7000/mach_ipi.h => es7000/ipi.h} | 6 +-
.../mach_mpparse.h => es7000/mpparse.h} | 4 +-
.../mach_wakecpu.h => es7000/wakecpu.h} | 6 +-
include/asm-x86/fb.h | 6 +-
include/asm-x86/fixmap.h | 6 +-
include/asm-x86/fixmap_32.h | 6 +-
include/asm-x86/fixmap_64.h | 6 +-
include/asm-x86/floppy.h | 6 +-
include/asm-x86/ftrace.h | 6 +-
include/asm-x86/futex.h | 6 +-
include/asm-x86/gart.h | 6 +-
include/asm-x86/genapic_32.h | 8 +-
include/asm-x86/genapic_64.h | 14 +-
include/asm-x86/geode.h | 6 +-
include/asm-x86/gpio.h | 2 +-
include/asm-x86/hardirq_32.h | 6 +-
include/asm-x86/hardirq_64.h | 6 +-
include/asm-x86/highmem.h | 6 +-
include/asm-x86/hpet.h | 6 +-
include/asm-x86/hugetlb.h | 6 +-
include/asm-x86/hw_irq.h | 35 +-
include/asm-x86/hypertransport.h | 6 +-
include/asm-x86/i387.h | 9 +-
include/asm-x86/i8253.h | 6 +-
include/asm-x86/i8259.h | 9 +-
include/asm-x86/ia32.h | 6 +-
include/asm-x86/ia32_unistd.h | 6 +-
include/asm-x86/idle.h | 6 +-
include/asm-x86/intel_arch_perfmon.h | 6 +-
include/asm-x86/io.h | 8 +-
include/asm-x86/io_32.h | 6 +-
include/asm-x86/io_64.h | 7 +-
include/asm-x86/io_apic.h | 26 +-
include/asm-x86/ioctls.h | 6 +-
include/asm-x86/iommu.h | 6 +-
include/asm-x86/ipcbuf.h | 6 +-
include/asm-x86/ipi.h | 22 +-
include/asm-x86/irq.h | 9 +-
include/asm-x86/irq_regs_32.h | 6 +-
include/asm-x86/irq_remapping.h | 8 +
include/asm-x86/irq_vectors.h | 30 +-
include/asm-x86/ist.h | 6 +-
include/asm-x86/k8.h | 6 +-
include/asm-x86/kdebug.h | 6 +-
include/asm-x86/kexec.h | 6 +-
include/asm-x86/kgdb.h | 6 +-
include/asm-x86/kmap_types.h | 6 +-
include/asm-x86/kprobes.h | 6 +-
include/asm-x86/kvm.h | 6 +-
include/asm-x86/kvm_host.h | 8 +-
include/asm-x86/kvm_para.h | 6 +-
include/asm-x86/kvm_x86_emulate.h | 6 +-
include/asm-x86/ldt.h | 6 +-
include/asm-x86/lguest.h | 6 +-
include/asm-x86/lguest_hcall.h | 6 +-
include/asm-x86/linkage.h | 6 +-
include/asm-x86/local.h | 6 +-
include/asm-x86/mach-default/apm.h | 6 +-
include/asm-x86/mach-default/entry_arch.h | 1 +
include/asm-x86/mach-default/mach_apic.h | 23 +-
include/asm-x86/mach-default/mach_apicdef.h | 12 +-
include/asm-x86/mach-default/mach_ipi.h | 6 +-
include/asm-x86/mach-default/mach_mpparse.h | 6 +-
include/asm-x86/mach-default/mach_mpspec.h | 6 +-
include/asm-x86/mach-default/mach_timer.h | 6 +-
include/asm-x86/mach-default/mach_traps.h | 6 +-
include/asm-x86/mach-default/mach_wakecpu.h | 6 +-
include/asm-x86/mach-es7000/mach_apicdef.h | 13 -
include/asm-x86/mach-generic/gpio.h | 6 +-
include/asm-x86/mach-generic/irq_vectors_limits.h | 14 -
include/asm-x86/mach-generic/mach_apic.h | 7 +-
include/asm-x86/mach-generic/mach_apicdef.h | 6 +-
include/asm-x86/mach-generic/mach_ipi.h | 6 +-
include/asm-x86/mach-generic/mach_mpparse.h | 6 +-
include/asm-x86/mach-generic/mach_mpspec.h | 6 +-
include/asm-x86/mach-rdc321x/gpio.h | 6 +-
include/asm-x86/mach-summit/irq_vectors_limits.h | 14 -
include/asm-x86/mach-summit/mach_apicdef.h | 13 -
include/asm-x86/math_emu.h | 6 +-
include/asm-x86/mc146818rtc.h | 6 +-
include/asm-x86/mca.h | 6 +-
include/asm-x86/mca_dma.h | 6 +-
include/asm-x86/mce.h | 6 +-
include/asm-x86/mman.h | 6 +-
include/asm-x86/mmconfig.h | 6 +-
include/asm-x86/mmu.h | 6 +-
include/asm-x86/mmu_context.h | 6 +-
include/asm-x86/mmu_context_32.h | 6 +-
include/asm-x86/mmu_context_64.h | 6 +-
include/asm-x86/mmx.h | 6 +-
include/asm-x86/mmzone_32.h | 6 +-
include/asm-x86/mmzone_64.h | 6 +-
include/asm-x86/module.h | 6 +-
include/asm-x86/mpspec.h | 7 +-
include/asm-x86/mpspec_def.h | 6 +-
include/asm-x86/msgbuf.h | 6 +-
include/asm-x86/msidef.h | 10 +-
include/asm-x86/msr-index.h | 6 +-
include/asm-x86/msr.h | 6 +-
include/asm-x86/mtrr.h | 6 +-
include/asm-x86/mutex_32.h | 6 +-
include/asm-x86/mutex_64.h | 6 +-
include/asm-x86/nmi.h | 6 +-
include/asm-x86/nops.h | 6 +-
include/asm-x86/numa_32.h | 6 +-
include/asm-x86/numa_64.h | 6 +-
include/asm-x86/numaq.h | 6 +-
.../{mach-numaq/mach_apic.h => numaq/apic.h} | 6 +-
.../{mach-numaq/mach_apicdef.h => numaq/apicdef.h} | 4 +-
.../asm-x86/{mach-numaq/mach_ipi.h => numaq/ipi.h} | 6 +-
.../{mach-numaq/mach_mpparse.h => numaq/mpparse.h} | 6 +-
.../{mach-numaq/mach_wakecpu.h => numaq/wakecpu.h} | 6 +-
include/asm-x86/olpc.h | 6 +-
include/asm-x86/page.h | 6 +-
include/asm-x86/page_32.h | 7 +-
include/asm-x86/page_64.h | 7 +-
include/asm-x86/param.h | 6 +-
include/asm-x86/paravirt.h | 25 +-
include/asm-x86/parport.h | 6 +-
include/asm-x86/pat.h | 6 +-
include/asm-x86/pci-direct.h | 6 +-
include/asm-x86/pci.h | 6 +-
include/asm-x86/pci_32.h | 6 +-
include/asm-x86/pci_64.h | 6 +-
include/asm-x86/pda.h | 6 +-
include/asm-x86/percpu.h | 6 +-
include/asm-x86/pgalloc.h | 6 +-
include/asm-x86/pgtable-2level-defs.h | 6 +-
include/asm-x86/pgtable-2level.h | 6 +-
include/asm-x86/pgtable-3level-defs.h | 6 +-
include/asm-x86/pgtable-3level.h | 6 +-
include/asm-x86/pgtable.h | 8 +-
include/asm-x86/pgtable_32.h | 7 +-
include/asm-x86/pgtable_64.h | 6 +-
include/asm-x86/posix_types_32.h | 6 +-
include/asm-x86/posix_types_64.h | 6 +-
include/asm-x86/prctl.h | 6 +-
include/asm-x86/processor-flags.h | 6 +-
include/asm-x86/processor.h | 10 +-
include/asm-x86/proto.h | 6 +-
include/asm-x86/ptrace-abi.h | 6 +-
include/asm-x86/ptrace.h | 9 +-
include/asm-x86/pvclock-abi.h | 6 +-
include/asm-x86/pvclock.h | 6 +-
include/asm-x86/reboot.h | 6 +-
include/asm-x86/reboot_fixups.h | 6 +-
include/asm-x86/required-features.h | 6 +-
include/asm-x86/resume-trace.h | 6 +-
include/asm-x86/rio.h | 6 +-
include/asm-x86/rwlock.h | 6 +-
include/asm-x86/rwsem.h | 6 +-
include/asm-x86/scatterlist.h | 6 +-
include/asm-x86/seccomp_32.h | 6 +-
include/asm-x86/seccomp_64.h | 6 +-
include/asm-x86/segment.h | 6 +-
include/asm-x86/sembuf.h | 6 +-
include/asm-x86/serial.h | 6 +-
include/asm-x86/setup.h | 8 +-
include/asm-x86/shmbuf.h | 6 +-
include/asm-x86/shmparam.h | 6 +-
include/asm-x86/sigcontext.h | 6 +-
include/asm-x86/sigcontext32.h | 6 +-
include/asm-x86/siginfo.h | 6 +-
include/asm-x86/signal.h | 9 +-
include/asm-x86/smp.h | 27 +-
include/asm-x86/socket.h | 6 +-
include/asm-x86/sockios.h | 6 +-
include/asm-x86/sparsemem.h | 6 +-
include/asm-x86/spinlock.h | 6 +-
include/asm-x86/spinlock_types.h | 6 +-
include/asm-x86/srat.h | 6 +-
include/asm-x86/stacktrace.h | 6 +-
include/asm-x86/stat.h | 6 +-
include/asm-x86/statfs.h | 6 +-
include/asm-x86/string_32.h | 6 +-
include/asm-x86/string_64.h | 6 +-
.../{mach-summit/mach_apic.h => summit/apic.h} | 24 +-
include/asm-x86/summit/apicdef.h | 13 +
.../{mach-summit/mach_ipi.h => summit/ipi.h} | 6 +-
.../mach_mpparse.h => summit/mpparse.h} | 13 +-
include/asm-x86/suspend_32.h | 6 +-
include/asm-x86/suspend_64.h | 6 +-
include/asm-x86/swiotlb.h | 6 +-
include/asm-x86/sync_bitops.h | 6 +-
include/asm-x86/syscalls.h | 93 ++
include/asm-x86/system.h | 6 +-
include/asm-x86/system_64.h | 6 +-
include/asm-x86/tce.h | 6 +-
include/asm-x86/termbits.h | 6 +-
include/asm-x86/termios.h | 6 +-
include/asm-x86/therm_throt.h | 6 +-
include/asm-x86/thread_info.h | 6 +-
include/asm-x86/time.h | 8 +-
include/asm-x86/timer.h | 11 +-
include/asm-x86/timex.h | 6 +-
include/asm-x86/tlb.h | 6 +-
include/asm-x86/tlbflush.h | 6 +-
include/asm-x86/topology.h | 6 +-
include/asm-x86/trampoline.h | 6 +-
include/asm-x86/traps.h | 10 +-
include/asm-x86/tsc.h | 6 +-
include/asm-x86/types.h | 6 +-
include/asm-x86/uaccess.h | 6 +-
include/asm-x86/uaccess_32.h | 6 +-
include/asm-x86/uaccess_64.h | 6 +-
include/asm-x86/ucontext.h | 6 +-
include/asm-x86/unaligned.h | 6 +-
include/asm-x86/unistd_32.h | 6 +-
include/asm-x86/unistd_64.h | 6 +-
include/asm-x86/unwind.h | 6 +-
include/asm-x86/user32.h | 6 +-
include/asm-x86/user_32.h | 6 +-
include/asm-x86/user_64.h | 6 +-
include/asm-x86/uv/bios.h | 6 +-
include/asm-x86/uv/uv_bau.h | 6 +-
include/asm-x86/uv/uv_hub.h | 6 +-
include/asm-x86/uv/uv_mmrs.h | 6 +-
include/asm-x86/vdso.h | 6 +-
include/asm-x86/vga.h | 6 +-
include/asm-x86/vgtod.h | 6 +-
include/asm-x86/visws/cobalt.h | 6 +-
include/asm-x86/visws/lithium.h | 6 +-
include/asm-x86/visws/piix4.h | 6 +-
include/asm-x86/vm86.h | 6 +-
include/asm-x86/vmi_time.h | 6 +-
include/asm-x86/vsyscall.h | 6 +-
include/asm-x86/xen/events.h | 6 +-
include/asm-x86/xen/grant_table.h | 6 +-
include/asm-x86/xen/hypercall.h | 6 +-
include/asm-x86/xen/hypervisor.h | 6 +-
include/asm-x86/xen/interface.h | 6 +-
include/asm-x86/xen/interface_32.h | 6 +-
include/asm-x86/xen/interface_64.h | 6 +-
include/asm-x86/xen/page.h | 6 +-
include/linux/dmar.h | 127 ++-
include/linux/hpet.h | 14 +-
include/linux/init.h | 44 +
include/linux/interrupt.h | 7 +
include/linux/irq.h | 121 ++-
include/linux/kernel_stat.h | 20 +-
init/main.c | 129 ++-
kernel/irq/autoprobe.c | 20 +-
kernel/irq/chip.c | 105 +-
kernel/irq/handle.c | 297 ++++-
kernel/irq/internals.h | 4 +-
kernel/irq/manage.c | 82 +-
kernel/irq/migration.c | 25 +-
kernel/irq/proc.c | 44 +-
kernel/irq/resend.c | 6 +-
kernel/irq/spurious.c | 147 ++-
582 files changed, 7920 insertions(+), 3696 deletions(-)
create mode 100644 Documentation/timers/00-INDEX
rename Documentation/{ => timers}/hpet.txt (81%)
rename arch/x86/{mach-es7000 => es7000}/Makefile (100%)
rename arch/x86/{mach-es7000 => es7000}/es7000.h (89%)
rename arch/x86/{mach-es7000 => es7000}/es7000plat.c (99%)
create mode 100644 arch/x86/kernel/genx2apic_cluster.c
create mode 100644 arch/x86/kernel/genx2apic_phys.c
create mode 100644 drivers/pci/dma_remapping.h
create mode 100644 drivers/pci/intr_remapping.c
create mode 100644 drivers/pci/intr_remapping.h
rename include/asm-x86/{mach-bigsmp/mach_apic.h => bigsmp/apic.h} (98%)
rename include/asm-x86/{mach-bigsmp/mach_apicdef.h => bigsmp/apicdef.h} (74%)
rename include/asm-x86/{mach-bigsmp/mach_ipi.h => bigsmp/ipi.h} (100%)
rename include/asm-x86/{mach-es7000/mach_apic.h => es7000/apic.h} (92%)
create mode 100644 include/asm-x86/es7000/apicdef.h
rename include/asm-x86/{mach-es7000/mach_ipi.h => es7000/ipi.h} (83%)
rename include/asm-x86/{mach-es7000/mach_mpparse.h => es7000/mpparse.h} (91%)
rename include/asm-x86/{mach-es7000/mach_wakecpu.h => es7000/wakecpu.h} (95%)
create mode 100644 include/asm-x86/irq_remapping.h
delete mode 100644 include/asm-x86/mach-es7000/mach_apicdef.h
delete mode 100644 include/asm-x86/mach-generic/irq_vectors_limits.h
delete mode 100644 include/asm-x86/mach-summit/irq_vectors_limits.h
delete mode 100644 include/asm-x86/mach-summit/mach_apicdef.h
rename include/asm-x86/{mach-numaq/mach_apic.h => numaq/apic.h} (97%)
rename include/asm-x86/{mach-numaq/mach_apicdef.h => numaq/apicdef.h} (75%)
rename include/asm-x86/{mach-numaq/mach_ipi.h => numaq/ipi.h} (83%)
rename include/asm-x86/{mach-numaq/mach_mpparse.h => numaq/mpparse.h} (50%)
rename include/asm-x86/{mach-numaq/mach_wakecpu.h => numaq/wakecpu.h} (91%)
rename include/asm-x86/{mach-summit/mach_apic.h => summit/apic.h} (94%)
create mode 100644 include/asm-x86/summit/apicdef.h
rename include/asm-x86/{mach-summit/mach_ipi.h => summit/ipi.h} (83%)
rename include/asm-x86/{mach-summit/mach_mpparse.h => summit/mpparse.h} (96%)
create mode 100644 include/asm-x86/syscalls.hPATCH 1/1 irq: sparse irqs, fix
Quoted 2 lines
From
547c9dd238f4412622fb6a2622d81c35c0a9fb85Mon Sep 17 00:00:00 2001
From: Ingo Molnar <[email protected]>
Date: Thu, 14 Aug 2008 15:32:59 +0200
Subject: [PATCH] irq: sparse irqs, fix
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
fix:
drivers/pci/intel-iommu.c: In function ‘dmar_set_interrupt':drivers/pci/intel-iommu.c:918: error: too few arguments to function ‘create_irq'
--- drivers/pci/intel-iommu.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/pci/intel-iommu.c +1 -1
@@ -915,7 +915,7 @@ int dmar_set_interrupt(struct intel_iommu *iommu) {int irq, ret; - irq =create_irq (); + irq =create_irq (0 );if (!irq) {printk (KERN_ERR "IOMMU: no free vectors\n" );return -EINVAL ;
PATCH 1/1 irq: sparse irqs, fix #2
In reply to Ingo MolnarQuoted 2 lines
From
28f153577fc82ff93cd63472134b40f0634bff70Mon Sep 17 00:00:00 2001
From: Ingo Molnar <[email protected]>
Date: Thu, 14 Aug 2008 15:38:50 +0200
Subject: [PATCH] irq: sparse irqs, fix #2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
fix:
In file included from arch/x86/kernel/setup.c:99:
include/asm-x86/mach-default/mach_apic.h:142: error: expected ‘)’ before ‘->’ token
That hunk got mis-merged.
--- include/asm-x86/mach-default/mach_apic.h | 27 ++++++++++++++------------- 1 files changed, 14 insertions(+), 13 deletions(-)
include/asm-x86/mach-default/mach_apic.h +14 -13
@@ -85,6 +85,20 @@ static inline int apicid_to_node(int logical_apicid)return 0 ; #endif } + +static inline cpumask_t vector_allocation_domain (int cpu) +{ +/* Careful. Some cpus do not strictly honor the set of cpus +* specified in the interrupt destination when using lowest +* priority interrupt delivery mode. +* +* In particular there was a hyperthreading cpu observed to +* deliver interrupts to the wrong hyperthread when only one +* hyperthread was specified in the interrupt desitination. +*/ +cpumask_t domain = { { [0 ] =APIC_ALL_CPUS , } }; +return domain; +}#endif static inline unsigned long check_apicid_used (physid_mask_t bitmap,int apicid)
@@ -139,18 +153,5 @@ static inline void enable_apic_mode(void) { } -static inline cpumask_t vector_allocation_domain (int cpu) -{ -/* Careful. Some cpus do not strictly honor the set of cpus -* specified in the interrupt destination when using lowest -* priority interrupt delivery mode. -* -* In particular there was a hyperthreading cpu observed to -* deliver interrupts to the wrong hyperthread when only one -* hyperthread was specified in the interrupt desitination. -*/ -cpumask_t domain = { { [0 ] =APIC_ALL_CPUS , } }; -return domain; -}#endif /* CONFIG_X86_LOCAL_APIC */ #endif /* ASM_X86__MACH_DEFAULT__MACH_APIC_H */
Re: [PATCH] irq: sparse irqs, fix #2
include/asm-x86/mach-default/mach_apic.h static inline int apicid_to_node(int logical_apicid) · line 101
Quoted 13 lines · On Thu, 14 Aug 2008 15:36:52 +0200 Ingo Molnar <[email protected]> wrote:
include/asm-x86/mach-default/mach_apic.h +13
-0+static inline cpumask_t vector_allocation_domain (int cpu) +{ +/* Careful. Some cpus do not strictly honor the set of cpus +* specified in the interrupt destination when using lowest +* priority interrupt delivery mode. +* +* In particular there was a hyperthreading cpu observed to +* deliver interrupts to the wrong hyperthread when only one +* hyperthread was specified in the interrupt desitination. +*/ +cpumask_t domain = { { [0 ] =APIC_ALL_CPUS , } }; +return domain; +}
I haven't looked at callers of this, but...
Does it need to be allocated on the stack? Local cpumask_t's are a size problem. Can we build this in .rodata at compile time instead?
Is this the caller?
+ for_each_cpu_mask(cpu, mask) {
+ cpumask_t domain, new_mask;
+ int new_cpu;
+ int vector;
+
+ domain = vector_allocation_domain(cpu);
+ cpus_and(new_mask, domain, cpu_online_map);
If so we could perhaps do
static noinline const cpumask_t *vector_allocation_domain(int cpu) {
/* Careful. Some cpus do not strictly honor the set of cpus
* specified in the interrupt destination when using lowest
* priority interrupt delivery mode.
*
* In particular there was a hyperthreading cpu observed to
* deliver interrupts to the wrong hyperthread when only one
* hyperthread was specified in the interrupt desitination. */
static const cpumask_t domain = { { [0] = APIC_ALL_CPUS, } }; return &domain;
}
...
+ for_each_cpu_mask(cpu, mask) {
+ cpumask_t domain, new_mask;
+ int new_cpu;
+ int vector;
+
+ __cpus_and(new_mask, vector_allocation_domain(cpu),
+ &cpu_online_map);
otoh, perhaps this new function is one implementation of genapic.vector_allocation_domain(), in which case the inlining was unneeded and misleading.
I give up. Have a little think about the stack bloat, please.
btw, whoever wrote that function is in need of a tab key.
Re: [PATCH] irq: sparse irqs, fix #2
Quoted 18 lines · Andrew Morton
include/asm-x86/mach-default/mach_apic.h static inline int apicid_to_node(int logical_apicid) · line 101
Quoted 13 lines · On Thu, 14 Aug 2008 15:36:52 +0200 Ingo Molnar <[email protected]> wrote:
include/asm-x86/mach-default/mach_apic.h +13
-0+static inline cpumask_t vector_allocation_domain (int cpu) +{ +/* Careful. Some cpus do not strictly honor the set of cpus +* specified in the interrupt destination when using lowest +* priority interrupt delivery mode. +* +* In particular there was a hyperthreading cpu observed to +* deliver interrupts to the wrong hyperthread when only one +* hyperthread was specified in the interrupt desitination. +*/ +cpumask_t domain = { { [0 ] =APIC_ALL_CPUS , } }; +return domain; +}I haven't looked at callers of this, but...
Quoted 4 lines
Does it need to be allocated on the stack? Local cpumask_t's are a size problem. Can we build this in .rodata at compile time instead?
Is this the caller?
Yes.
Quoted 37 lines
(quoted diff) +7
-0+ for_each_cpu_mask(cpu, mask) { + cpumask_t domain, new_mask; + int new_cpu; + int vector; + + domain = vector_allocation_domain(cpu); + cpus_and(new_mask, domain, cpu_online_map);If so we could perhaps do
static noinline const
cpumask_t*vector_allocation_domain(int cpu) {
/* Careful. Some cpus do not strictly honor the set of cpus
* specified in the interrupt destination when using lowest
* priority interrupt delivery mode.
*
* In particular there was a hyperthreading cpu observed to
* deliver interrupts to the wrong hyperthread when only one
* hyperthread was specified in the interrupt desitination. */
static constcpumask_tdomain = { { [0] =APIC_ALL_CPUS, } }; return &domain;
}...
(quoted diff) +7
-0+ for_each_cpu_mask(cpu, mask) { + cpumask_t domain, new_mask; + int new_cpu; + int vector; + + __cpus_and(new_mask, vector_allocation_domain(cpu), + &cpu_online_map);
Quoted 3 lines
otoh, perhaps this new function is one implementation of
genapic.vector_allocation_domain(), in which case the inlining was unneeded and misleading.
Likely. Why these things live in header files...
Quoted 3 lines
I give up. Have a little think about the stack bloat, please.
btw, whoever wrote that function is in need of a tab key.
Unfortunate gradual accreation of functionality.
vector_allocation_domain could perhaps be better named. Round up this cpu to the set of cpus I need to allocate a vector on.
Eric
PATCH 1/1 irq: sparse irqs, fix IRQ auto-probe crash
In reply to Ingo Molnarfind below a crash fix discovered by tip/master testing.
Robustness of sparse IRQs is looking pretty good otherwise at first glance.
Ingo
------------------>
Quoted 1 line
From
a4a5ec7bbaaaab5fcb86bd348b98bfbed7c6a3b7Mon Sep 17 00:00:00 2001
From: Ingo Molnar <[email protected]>
Date: Thu, 14 Aug 2008 15:48:50 +0200
Subject: [PATCH] irq: sparse irqs, fix IRQ auto-probe crash
fix:
[ 10.631533] calling yenta_socket_init+0x0/0x20 [ 10.631533] Yenta: CardBus bridge found at 0000:15:00.0 [17aa:2012] [ 10.631533] Yenta: Using INTVAL to route CSC interrupts to PCI [ 10.631533] Yenta: Routing CardBus interrupts to PCI [ 10.631533] Yenta TI: socket 0000:15:00.0, mfunc 0x01d01002, devctl 0x64 [ 10.731599] BUG: unable to handle kernel NULL pointer dereference at 00000040 [ 10.731838] IP: [<c0c95b5f>] _spin_lock_irq+0xf/0x20 [ 10.732221] *pde = 00000000 [ 10.732741] Oops: 0002 [#1] SMP [ 10.733453] [ 10.734253] Pid: 1, comm: swapper Tainted: G W (2.6.27-rc3-tip-00173-gd7eaa4f-dirty #1) [ 10.735188] EIP: 0060:[<c0c95b5f>] EFLAGS: 00010002 CPU: 0 [ 10.735523] EIP is at _spin_lock_irq+0xf/0x20 [ 10.735523] EAX: 00000040 EBX: 00000000 ECX: f6e04c90 EDX: 00000100 [ 10.735523] ESI: 000000df EDI: f6e04c90 EBP: f7867df0 ESP: f7867df0 [ 10.735523] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 [ 10.735523] Process swapper (pid: 1, ti=f7867000 task=f7870000 task.ti=f7867000) [ 10.735523] Stack: f7867e04 c0155fbd 00000000 00000000 f6e04c90 f7867e5c c0c6e319 c0f6a074 [ 10.735523] f6e04c90 000017aa 00002012 c112b648 f791f240 c112b5e0 f7867e44 c010440b [ 10.735523] f791f240 f791f29c c112b8ec f791f240 00000000 f7867e5c c048f893 03c0b648 [ 10.735523] Call Trace: [ 10.735523] [<c0155fbd>] ? probe_irq_on+0x3d/0x140 [ 10.735523] [<c0c6e319>] ? yenta_probe+0x529/0x640 [ 10.735523] [<c010440b>] ? mcount_call+0x5/0xa [ 10.735523] [<c048f893>] ? pci_match_device+0xa3/0xb0 [ 10.735523] [<c048fc1e>] ? pci_device_probe+0x5e/0x80 [ 10.735523] [<c0515423>] ? driver_probe_device+0x83/0x180 [ 10.735523] [<c0515594>] ? __driver_attach+0x74/0x80 [ 10.735523] [<c0514b69>] ? bus_for_each_dev+0x49/0x70 [ 10.735523] [<c051528e>] ? driver_attach+0x1e/0x20 [ 10.735523] [<c0515520>] ? __driver_attach+0x0/0x80 [ 10.735523] [<c05150d3>] ? bus_add_driver+0x1a3/0x220 [ 10.735523] [<c048fb60>] ? pci_device_remove+0x0/0x40 [ 10.735523] [<c05157f4>] ? driver_register+0x54/0x130 [ 10.735523] [<c048fe2f>] ? __pci_register_driver+0x4f/0x90 [ 10.735523] [<c11e9419>] ? yenta_socket_init+0x19/0x20 [ 10.735523] [<c0101125>] ? do_one_initcall+0x35/0x160 [ 10.735523] [<c11e9400>] ? yenta_socket_init+0x0/0x20 [ 10.735523] [<c01391a6>] ? __queue_work+0x36/0x50 [ 10.735523] [<c013922d>] ? queue_work_on+0x3d/0x50 [ 10.735523] [<c11a2758>] ? kernel_init+0x148/0x210 [ 10.735523] [<c11a2610>] ? kernel_init+0x0/0x210 [ 10.735523] [<c01043f3>] ? kernel_thread_helper+0x7/0x10 [ 10.735523] ======================= [ 10.735523] Code: 10 38 f2 74 06 f3 90 8a 10 eb f6 5d 89 c8 c3 8d b6 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5 e8 a4 e8 46 ff fa ba 00 01 00 00 90 <66> 0f c1 10 38 f2 74 06 f3 90 8a 10 eb f6 5d c3 90 55 89 e5 53
as auto-probing wants to iterate over existing irqs.
--- kernel/irq/autoprobe.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-)
kernel/irq/autoprobe.c +10 -0
@@ -40,6 +40,8 @@ unsigned long probe_irq_on(void)*/ for (i = nr_irqs-1 ; i >0 ; i--) { desc =irq_desc (i); +if (!desc) +continue ;spin_lock_irq (&desc->lock);if (!desc->action && !(desc->status &IRQ_NOPROBE )) {
@@ -70,6 +72,8 @@ unsigned long probe_irq_on(void)*/ for (i = nr_irqs-1 ; i >0 ; i--) { desc =irq_desc (i); +if (!desc) +continue ;spin_lock_irq (&desc->lock);if (!desc->action && !(desc->status &IRQ_NOPROBE )) {
@@ -93,6 +97,8 @@ unsigned long probe_irq_on(void)unsigned int status; desc =irq_desc (i); +if (!desc) +continue ;spin_lock_irq (&desc->lock); status = desc->status;
@@ -134,6 +140,8 @@ unsigned int probe_irq_mask(unsigned long val)struct irq_desc *desc =irq_desc (i);unsigned int status; +if (!desc) +continue ;spin_lock_irq (&desc->lock); status = desc->status;
@@ -177,6 +185,8 @@ int probe_irq_off(unsigned long val)struct irq_desc *desc =irq_desc (i);unsigned int status; +if (!desc) +continue ;spin_lock_irq (&desc->lock); status = desc->status;
PATCH 1/1 irq: sparse irqs, export nr_irqs
In reply to Ingo MolnarQuoted 2 lines
From
c239ac14984518f2f3b7a920367c79bb6c3180e4Mon Sep 17 00:00:00 2001
From: Ingo Molnar <[email protected]>
Date: Thu, 14 Aug 2008 15:58:26 +0200
Subject: [PATCH] irq: sparse irqs, export nr_irqs
fix:
Building modules, stage 2.
MODPOST 458 modules
ERROR: "nr_irqs" [drivers/serial/8250.ko] undefined!
--- kernel/irq/handle.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
kernel/irq/handle.c +1 -0
@@ -56,6 +56,7 @@ handle_bad_irq(unsigned int irq, struct irq_desc *desc)* Controller mappings for all interrupt sources: */ int nr_irqs =NR_IRQS ; +EXPORT_SYMBOL_GPL (nr_irqs);#ifdef CONFIG_HAVE_DYN_ARRAY static struct irq_desc irq_desc_init = {
PATCH 1/1 irq: sparse irqs, fix #3
In reply to Ingo MolnarQuoted 2 lines
From
1b53f0444df394e4448ba56694f0bc4dda2bece0Mon Sep 17 00:00:00 2001
From: Ingo Molnar <[email protected]>
Date: Thu, 14 Aug 2008 16:07:04 +0200
Subject: [PATCH] irq: sparse irqs, fix #3
fix non-APIC UP build:
arch/x86/kernel/built-in.o: In function `setup_arch':
: undefined reference to pin_map_size' arch/x86/kernel/built-in.o: In function setup_arch':
: undefined reference to `first_free_entry'
--- arch/x86/kernel/setup.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
arch/x86/kernel/setup.c +2 -0
@@ -863,8 +863,10 @@ void __init setup_arch(char **cmdline_p) nr_irqs =32 * nr_cpu_ids +224 ;init_cpu_to_node ();#endif +#ifdef CONFIG_X86_LOCAL_APIC pin_map_size = nr_irqs *2 ; first_free_entry = nr_irqs; +#endif init_apic_mappings ();ioapic_init_mappings ();
Re: [PATCH] irq: sparse irqs, fix #3
Quoted 24 lines · Ingo Molnar
From
1b53f0444df394e4448ba56694f0bc4dda2bece0Mon Sep 17 00:00:00 2001
From: Ingo Molnar <[email protected]>
Date: Thu, 14 Aug 2008 16:07:04 +0200
Subject: [PATCH] irq: sparse irqs, fix #3fix non-APIC UP build:
arch/x86/kernel/built-in.o: In function `setup_arch':
: undefined reference topin_map_size' arch/x86/kernel/built-in.o: In functionsetup_arch':
: undefined reference to `first_free_entry'Signed-off-by Ingo Molnar <[email protected]>--- arch/x86/kernel/setup.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)arch/x86/kernel/setup.c +0
-0
arch/x86/kernel/setup.c void __init setup_arch(char **cmdline_p) · line 872
Quoted 10 lines
arch/x86/kernel/setup.c +2
-0@@ -863,8 +863,10 @@ void __init setup_arch(char **cmdline_p) nr_irqs =32 * nr_cpu_ids +224 ;init_cpu_to_node ();#endif +#ifdef CONFIG_X86_LOCAL_APIC pin_map_size = nr_irqs *2 ; first_free_entry = nr_irqs; +#endif init_apic_mappings ();ioapic_init_mappings ();
we don't need pin_map_size and first_free_entry after 64 and 32 bit all put irq_2_pin in irq_cfg.
need to remove them.
YH
Quoted 24 lines · Ingo Molnar
(lkml Cc:-ed)
Quoted 11 lines · Yinghai Lu
v10: make the x86 32 bit support
sparse_irqtoo.
also make remove irqbalance in kernel for 32 bit
and make 32 bit supportper_cpuvector. so start merging orio_apic_xx.c01-03 is some fix for current tree
04: is revert for one patch hide in sched/ and tip/masterbased on tip/master
to do:
mergeio_apic_xx.cok, i've created a new tip/irq/sparseirq topic branch for this.
Could you please send future updates against:
git-checkout tip/master
git-merge tip/irq/sparseirq
Quoted 8 lines
Not yet integrated into tip/master, i've still got some other backlog.
A couple of observations about the general structure of the sparse irqs code:
- the new APIs should probably live in
mm/bootmem.cnot ininit/main.c, and inbootmem.h. Also, it should be outlined clearly why this new API is needed as a wrapper ontop of existing bootmem mechanisms.
movepre_alloc_dyn_array, per_cpu_dyn_array_size, per_cpu_alloc_dyn_array to mm/bootmem.c?
Quoted 5 lines
- the #ifdef complications, while fine for migration, should be eliminated. Could we introduce some compatible form for the definition/allocation APIs that work even if an architecture still uses a flat irq array? That would remove most of the uglinesses.
# git grep CONFIG_HAVE_DYN_ARRAY | wc -l 9
#git grep CONFIG_HAVE_SPARSE_IRQ | wc -l
39
arch/x86/kernel/io_apic_32.c:#ifdef CONFIG_HAVE_SPARSE_IRQ_DEBUG arch/x86/kernel/io_apic_32.c:#ifndef CONFIG_HAVE_SPARSE_IRQ arch/x86/kernel/io_apic_64.c:#ifdef CONFIG_HAVE_SPARSE_IRQ_DEBUG arch/x86/kernel/io_apic_64.c:#ifndef CONFIG_HAVE_SPARSE_IRQ arch/x86/kernel/irq_32.c:#ifdef CONFIG_HAVE_SPARSE_IRQ arch/x86/kernel/irq_64.c:#ifdef CONFIG_HAVE_SPARSE_IRQ drivers/char/random.c:#ifndef CONFIG_HAVE_SPARSE_IRQ drivers/char/random.c:#ifndef CONFIG_HAVE_SPARSE_IRQ drivers/pci/intr_remapping.c:#ifdef CONFIG_HAVE_SPARSE_IRQ drivers/pci/intr_remapping.c:#else /* !CONFIG_HAVE_SPARSE_IRQ */
drivers/pci/intr_remapping.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
fs/proc/proc_misc.c:#ifdef CONFIG_HAVE_SPARSE_IRQ fs/proc/proc_misc.c:#ifdef CONFIG_HAVE_SPARSE_IRQ fs/proc/proc_misc.c:#ifdef CONFIG_HAVE_SPARSE_IRQ include/linux/irq.h:#ifdef CONFIG_HAVE_SPARSE_IRQ include/linux/irq.h:#ifdef CONFIG_HAVE_SPARSE_IRQ include/linux/irq.h:#ifdef CONFIG_HAVE_SPARSE_IRQ include/linux/irq.h:#ifdef CONFIG_HAVE_SPARSE_IRQ include/linux/irq.h:#if defined(CONFIG_INTR_REMAP) && defined(CONFIG_HAVE_SPARSE_IRQ) include/linux/irq.h:#ifndef CONFIG_HAVE_SPARSE_IRQ kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ kernel/irq/handle.c:#ifndef CONFIG_HAVE_SPARSE_IRQ kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ_DEBUG kernel/irq/handle.c:#ifndef CONFIG_HAVE_SPARSE_IRQ kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ kernel/irq/manage.c:#ifdef CONFIG_HAVE_SPARSE_IRQ kernel/irq/manage.c:#ifdef CONFIG_HAVE_SPARSE_IRQ kernel/irq/migration.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
because try to avoid more api to be changed to take irq_desc as parameter.
Quoted 3 lines
- some of the irq < 16 checks in x86 look a bit ugly, can we do anything about them?
is_legacy_irq(irq) ? or legacy_irq(irq)?
Quoted 5 lines
- i think as a final-ish commit we should just remove the dyn-array define and make all architectures use this facility. You converted most of them - how many are still missing? Sparse-irq is more intrusive so that should probably stay a
Kconfigknob.
so when config_sparse_irq is not selected, need to use dyn_array to allocate irq_desc and irq_cfg, or just static array?
Quoted 8 lines
- there was one aspect of
NR_IRQSthat was nice and useful: it acted as a sanity check against BIOS bugs and driver bugs that pass in some irrealistically high irq number. Now we'll just try to allocate some really high IRQ and accept it. I _think_ there should be a single, simple 'absolute maximum IRQ number' define which should set the maximum possible IRQ number. Lets call itNR_IRQS_MAXor so, and set it to NR_CPUS*NR_IO_APICS*224 or so?
when sparse_irq is used, irq is [0, -1U]
driver could be irq_desc(irq) to check if irq is valid or not. and use irq_desc_with_new(new) to get a new one.
when generic_hardirqs is not used (s390, m68k, sparc), we need to create some stubs in linux/interrupt.h for them
Quoted 9 lines
- i'm a bit worried about linecount increase in general:
247 files changed, 3671 insertions(+), 2052 deletions(-)could we work on reducing that somewhat? The new infrastructure bits in
mm/*andkernel/irq/*will be unavoidable, what we should concentrate on is to make usage of the new facility just as straightforward, easy and compact as the old irq_desc[] usages.
before that we could use get_irq_desc() and get_irq_desc_without_new() and according to eric, i changed that to irq_desc_with_new and irq_desc().
so the array irq_desc[] need to be changed to irq_descX[] ( or *irq_desc to *irq_descX for dyn_array)
Quoted 7 lines
A worst-case example is
drivers/char/random.c: theCONFIG_HAVE_SPARSE_IRQandCONFIG_HAVE_DYN_ARRAY#ifdef jungle is not acceptable. I think the best way out is to convert the whole kernel to the new facilities (as safely as possible, without breaking other architectures), and making sure that the end result is easy to understand and intuitive.
# grep CONFIG_HAVE_ drivers/char/random.c #ifndef CONFIG_HAVE_SPARSE_IRQ #ifdef CONFIG_HAVE_DYN_ARRAY #ifndef CONFIG_HAVE_SPARSE_IRQ
just want to make other arch is untouched.
Quoted 5 lines
so i dont mind the current code as long as the extra complications are temporary during a safe conversion - but we should work on eliminating all those complications before thinking about upstream merging.
Quoted 7 lines
Ingo
-------------------->
the irq/sparseirq git tree can be picked up from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.gitirq/sparseirq
Thanks
Yinghai Lu
Quoted 101 lines · Yinghai Lu
Quoted 24 lines · Ingo Molnar
(lkml Cc:-ed)
Quoted 11 lines · Yinghai Lu
v10: make the x86 32 bit support
sparse_irqtoo.
also make remove irqbalance in kernel for 32 bit
and make 32 bit supportper_cpuvector. so start merging orio_apic_xx.c01-03 is some fix for current tree
04: is revert for one patch hide in sched/ and tip/masterbased on tip/master
to do:
mergeio_apic_xx.cok, i've created a new tip/irq/sparseirq topic branch for this.
Could you please send future updates against:
git-checkout tip/master
git-merge tip/irq/sparseirqQuoted 8 lines
Not yet integrated into tip/master, i've still got some other backlog.
A couple of observations about the general structure of the sparse irqs code:
- the new APIs should probably live in
mm/bootmem.cnot ininit/main.c, and inbootmem.h. Also, it should be outlined clearly why this new API is needed as a wrapper ontop of existing bootmem mechanisms.move
pre_alloc_dyn_array,per_cpu_dyn_array_size,per_cpu_alloc_dyn_arraytomm/bootmem.c?Quoted 5 lines
- the #ifdef complications, while fine for migration, should be eliminated. Could we introduce some compatible form for the definition/allocation APIs that work even if an architecture still uses a flat irq array? That would remove most of the uglinesses.
# git grep CONFIG_HAVE_DYN_ARRAY | wc -l 9#git grep
CONFIG_HAVE_SPARSE_IRQ| wc -l
39arch/x86/kernel/io_apic_32.c:#ifdef
CONFIG_HAVE_SPARSE_IRQ_DEBUGarch/x86/kernel/io_apic_32.c:#ifndefCONFIG_HAVE_SPARSE_IRQarch/x86/kernel/io_apic_64.c:#ifdefCONFIG_HAVE_SPARSE_IRQ_DEBUGarch/x86/kernel/io_apic_64.c:#ifndefCONFIG_HAVE_SPARSE_IRQarch/x86/kernel/irq_32.c:#ifdefCONFIG_HAVE_SPARSE_IRQarch/x86/kernel/irq_64.c:#ifdefCONFIG_HAVE_SPARSE_IRQdrivers/char/random.c:#ifndefCONFIG_HAVE_SPARSE_IRQdrivers/char/random.c:#ifndefCONFIG_HAVE_SPARSE_IRQdrivers/pci/intr_remapping.c:#ifdefCONFIG_HAVE_SPARSE_IRQdrivers/pci/intr_remapping.c:#else /* !CONFIG_HAVE_SPARSE_IRQ */
drivers/pci/intr_remapping.c:#ifndefCONFIG_HAVE_SPARSE_IRQ
fs/proc/proc_misc.c:#ifdefCONFIG_HAVE_SPARSE_IRQfs/proc/proc_misc.c:#ifdefCONFIG_HAVE_SPARSE_IRQfs/proc/proc_misc.c:#ifdefCONFIG_HAVE_SPARSE_IRQinclude/linux/irq.h:#ifdefCONFIG_HAVE_SPARSE_IRQinclude/linux/irq.h:#ifdefCONFIG_HAVE_SPARSE_IRQinclude/linux/irq.h:#ifdefCONFIG_HAVE_SPARSE_IRQinclude/linux/irq.h:#ifdefCONFIG_HAVE_SPARSE_IRQinclude/linux/irq.h:#ifdefined(CONFIG_INTR_REMAP)&&defined(CONFIG_HAVE_SPARSE_IRQ)include/linux/irq.h:#ifndefCONFIG_HAVE_SPARSE_IRQkernel/irq/chip.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/chip.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/chip.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/chip.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/chip.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifndefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQ_DEBUGkernel/irq/handle.c:#ifndefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/manage.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/manage.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/migration.c:#ifdefCONFIG_HAVE_SPARSE_IRQbecause try to avoid more api to be changed to take
irq_descas parameter.Quoted 3 lines
- some of the irq < 16 checks in x86 look a bit ugly, can we do anything about them?
is_legacy_irq(irq)? orlegacy_irq(irq)?Quoted 1 line
Quoted 16 lines
Quoted 4 lines
- i think as a final-ish commit we should just remove the dyn-array define and make all architectures use this facility. You converted most of them - how many are still missing? Sparse-irq is more intrusive so that should probably stay a
Kconfigknob.so when
config_sparse_irqis not selected, need to usedyn_arrayto allocateirq_descandirq_cfg, or just static array?Quoted 8 lines
- there was one aspect of
NR_IRQSthat was nice and useful: it acted as a sanity check against BIOS bugs and driver bugs that pass in some irrealistically high irq number. Now we'll just try to allocate some really high IRQ and accept it. I _think_ there should be a single, simple 'absolute maximum IRQ number' define which should set the maximum possible IRQ number. Lets call itNR_IRQS_MAXor so, and set it to NR_CPUS*NR_IO_APICS*224 or so?
We may want an is_valid_isa_irq() for drivers. Otherwise drivers should not be passing in irqs. And the request_irq path should valid the irq number but it should not allocate it. So we will have failures with invalid irq numbers.
For acpi, mptables and the like we can easily have a check for some reasonably high value if there is value in that. Last I looked parts of that code were using numbers like 1024 and 4096 already.
Quoted 3 lines
when
sparse_irqis used, irq is [0, -1U]
driver could beirq_desc(irq)to check if irq is valid or not. and useirq_desc_with_new(new)to get a new one.
Note that request_irq should do this for free.
Quoted 2 lines
when
generic_hardirqsis not used (s390, m68k, sparc), we need to create some stubs inlinux/interrupt.hfor them
s390 is weird. I'm not even convinced they use linux/interrupt.h
Yep. If we need more than the proper checks in request_irq.
Quoted 8 lines
Quoted 8 lines
- i'm a bit worried about linecount increase in general:
247 files changed, 3671 insertions(+), 2052 deletions(-)could we work on reducing that somewhat? The new infrastructure bits in
mm/*andkernel/irq/*will be unavoidable, what we should concentrate on is to make usage of the new facility just as straightforward, easy and compact as the old irq_desc[] usages.
Quoted 5 lines
before that we could use
get_irq_desc()andget_irq_desc_without_new()and according to eric, i changed that toirq_desc_with_newandirq_desc().so the array irq_desc[] need to be changed to irq_descX[] ( or
*irq_descto*irq_descXfordyn_array)
My mistake. irq_desc() is a bad name for the conversion method because it conflicts like that. I really just did not want something wordy, or something that suggests you need to call put_irq_desc. BothÜ of which get_irq_desc() are.
What I wound up using in my tree is a little different.
I introduced an opaque/empty structure: struct irq to be used in places where we need pointers instead of an integer irq number in the interfaces.
I have a version of the genirq api that works on struct irq instead of unsigned int irq.
I have functions:
struct irq * to_irq(unsigned int nr);
struct irq_desc *to_idesc(struct irq *);
unsigned int irq_nr(struct irq *irq);
Is there any reason why the migration path for architectures can not be:
Until they are converted:
#define NR_IRQS and use the irq_desc array.
If they are just using a dynamically allocated array. #define NR_IRQS nr_irqs
Once we kill the array entirely.
#undef NR_IRQS or
#define NR_IRQS 0xfffff000
Quoted 7 lines
Quoted 6 lines
A worst-case example is
drivers/char/random.c: theCONFIG_HAVE_SPARSE_IRQandCONFIG_HAVE_DYN_ARRAY#ifdef jungle is not acceptable. I think the best way out is to convert the whole kernel to the new facilities (as safely as possible, without breaking other architectures), and making sure that the end result is easy to understand and intuitive.
Quoted 6 lines
# grep CONFIG_HAVE_ drivers/char/random.c #ifndef CONFIG_HAVE_SPARSE_IRQ #ifdef CONFIG_HAVE_DYN_ARRAY #ifndef CONFIG_HAVE_SPARSE_IRQjust want to make other arch is untouched.
It doesn't matter. If you look only genirq arches use use random irqs.
Eric
Quoted 153 lines · Eric W. Biederman
Quoted 101 lines · Yinghai Lu
Quoted 24 lines · Ingo Molnar
(lkml Cc:-ed)
Quoted 11 lines · Yinghai Lu
v10: make the x86 32 bit support
sparse_irqtoo.
also make remove irqbalance in kernel for 32 bit
and make 32 bit supportper_cpuvector. so start merging orio_apic_xx.c01-03 is some fix for current tree
04: is revert for one patch hide in sched/ and tip/masterbased on tip/master
to do:
mergeio_apic_xx.cok, i've created a new tip/irq/sparseirq topic branch for this.
Could you please send future updates against:
git-checkout tip/master
git-merge tip/irq/sparseirqQuoted 8 lines
Not yet integrated into tip/master, i've still got some other backlog.
A couple of observations about the general structure of the sparse irqs code:
- the new APIs should probably live in
mm/bootmem.cnot ininit/main.c, and inbootmem.h. Also, it should be outlined clearly why this new API is needed as a wrapper ontop of existing bootmem mechanisms.move
pre_alloc_dyn_array,per_cpu_dyn_array_size,per_cpu_alloc_dyn_arraytomm/bootmem.c?Quoted 5 lines
- the #ifdef complications, while fine for migration, should be eliminated. Could we introduce some compatible form for the definition/allocation APIs that work even if an architecture still uses a flat irq array? That would remove most of the uglinesses.
# git grep CONFIG_HAVE_DYN_ARRAY | wc -l 9#git grep
CONFIG_HAVE_SPARSE_IRQ| wc -l
39arch/x86/kernel/io_apic_32.c:#ifdef
CONFIG_HAVE_SPARSE_IRQ_DEBUGarch/x86/kernel/io_apic_32.c:#ifndefCONFIG_HAVE_SPARSE_IRQarch/x86/kernel/io_apic_64.c:#ifdefCONFIG_HAVE_SPARSE_IRQ_DEBUGarch/x86/kernel/io_apic_64.c:#ifndefCONFIG_HAVE_SPARSE_IRQarch/x86/kernel/irq_32.c:#ifdefCONFIG_HAVE_SPARSE_IRQarch/x86/kernel/irq_64.c:#ifdefCONFIG_HAVE_SPARSE_IRQdrivers/char/random.c:#ifndefCONFIG_HAVE_SPARSE_IRQdrivers/char/random.c:#ifndefCONFIG_HAVE_SPARSE_IRQdrivers/pci/intr_remapping.c:#ifdefCONFIG_HAVE_SPARSE_IRQdrivers/pci/intr_remapping.c:#else /* !CONFIG_HAVE_SPARSE_IRQ */
drivers/pci/intr_remapping.c:#ifndefCONFIG_HAVE_SPARSE_IRQ
fs/proc/proc_misc.c:#ifdefCONFIG_HAVE_SPARSE_IRQfs/proc/proc_misc.c:#ifdefCONFIG_HAVE_SPARSE_IRQfs/proc/proc_misc.c:#ifdefCONFIG_HAVE_SPARSE_IRQinclude/linux/irq.h:#ifdefCONFIG_HAVE_SPARSE_IRQinclude/linux/irq.h:#ifdefCONFIG_HAVE_SPARSE_IRQinclude/linux/irq.h:#ifdefCONFIG_HAVE_SPARSE_IRQinclude/linux/irq.h:#ifdefCONFIG_HAVE_SPARSE_IRQinclude/linux/irq.h:#ifdefined(CONFIG_INTR_REMAP)&&defined(CONFIG_HAVE_SPARSE_IRQ)include/linux/irq.h:#ifndefCONFIG_HAVE_SPARSE_IRQkernel/irq/chip.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/chip.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/chip.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/chip.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/chip.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifndefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQ_DEBUGkernel/irq/handle.c:#ifndefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/manage.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/manage.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/migration.c:#ifdefCONFIG_HAVE_SPARSE_IRQbecause try to avoid more api to be changed to take
irq_descas parameter.Quoted 3 lines
- some of the irq < 16 checks in x86 look a bit ugly, can we do anything about them?
is_legacy_irq(irq)? orlegacy_irq(irq)?Quoted 1 line
Quoted 16 lines
Quoted 4 lines
- i think as a final-ish commit we should just remove the dyn-array define and make all architectures use this facility. You converted most of them - how many are still missing? Sparse-irq is more intrusive so that should probably stay a
Kconfigknob.so when
config_sparse_irqis not selected, need to usedyn_arrayto allocateirq_descandirq_cfg, or just static array?Quoted 8 lines
- there was one aspect of
NR_IRQSthat was nice and useful: it acted as a sanity check against BIOS bugs and driver bugs that pass in some irrealistically high irq number. Now we'll just try to allocate some really high IRQ and accept it. I _think_ there should be a single, simple 'absolute maximum IRQ number' define which should set the maximum possible IRQ number. Lets call itNR_IRQS_MAXor so, and set it to NR_CPUS*NR_IO_APICS*224 or so?We may want an
is_valid_isa_irq()for drivers. Otherwise drivers should not be passing in irqs. And therequest_irqpath should valid the irq number but it should not allocate it. So we will have failures with invalid irq numbers.For acpi, mptables and the like we can easily have a check for some reasonably high value if there is value in that. Last I looked parts of that code were using numbers like 1024 and 4096 already.
Quoted 3 lines
when
sparse_irqis used, irq is [0, -1U]
driver could beirq_desc(irq)to check if irq is valid or not. and useirq_desc_with_new(new)to get a new one.Note that
request_irqshould do this for free.Quoted 2 lines
when
generic_hardirqsis not used (s390, m68k, sparc), we need to create some stubs inlinux/interrupt.hfor thems390 is weird. I'm not even convinced they use
linux/interrupt.hYep. If we need more than the proper checks in
request_irq.Quoted 11 lines
Quoted 8 lines
- i'm a bit worried about linecount increase in general:
247 files changed, 3671 insertions(+), 2052 deletions(-)could we work on reducing that somewhat? The new infrastructure bits in
mm/*andkernel/irq/*will be unavoidable, what we should concentrate on is to make usage of the new facility just as straightforward, easy and compact as the old irq_desc[] usages.before that we could use
get_irq_desc()andget_irq_desc_without_new()and according to eric, i changed that toirq_desc_with_newandirq_desc().
Quoted 7 lines
Quoted 2 lines
so the array irq_desc[] need to be changed to irq_descX[] ( or
*irq_descto*irq_descXfordyn_array)My mistake.
irq_desc()is a bad name for the conversion method because it conflicts like that. I really just did not want something wordy, or something that suggests you need to callput_irq_desc. BothÜ of whichget_irq_desc()are.
it took me one day to change them. anyway irq_desc() is better than get_irq_desc
Quoted 6 lines
What I wound up using in my tree is a little different.
I introduced an opaque/empty structure: struct irq to be used in places where we need pointers instead of an integer irq number in the interfaces.
Quoted 7 lines
I have a version of the genirq api that works on struct irq instead of unsigned int irq.
I have functions:
struct irq *to_irq(unsigned int nr);
structirq_desc*to_idesc(struct irq *);
unsigned intirq_nr(struct irq *irq);
struct irq {
unsigned int nr;
struct irq_desc *idesc;
}
?
Quoted 11 lines
Is there any reason why the migration path for architectures can not be:
Until they are converted:
#defineNR_IRQSand use theirq_descarray.If they are just using a dynamically allocated array. #define
NR_IRQSnr_irqsOnce we kill the array entirely.
#undefNR_IRQSor
#defineNR_IRQS0xfffff000
why not use -1U here?
YH
find something interesting:
found new irq_cfg for irq 20
0 add_pin_to_irq: irq 20 --> apic 0 pin 20assign_irq_vector: irq 20 vector 0x59 cpu 5
IOAPIC[0]: Set routing entry (0-20 -> 0x59 -> IRQ 20 Mode:1 Active:1) found new irq_desc for irq 20
pci 0000:00:02.1: PCI INT B -> Link[LUS2] -> GSI 20 (level, low) -> IRQ 20
IO APIC #0......
.... register #00: 00000000
....... : physical APIC id: 00 ....... : Delivery Type: 0 ....... : LTS : 0 .... register #01: 00170011 ....... : max redirection entries: 0017 ....... : PRQ implemented: 0 ....... : IO APIC version: 0011
.... register #02: 00000000
....... : arbitration: 00
.... IRQ redirection table:
NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect:
...
14 09 1 1 0 1 0 0 0 59
...
ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004do_IRQ: cannot handle IRQ -1 vector 0x59 cpu 0
------------[ cut here ]------------ Kernel BUG at 40206b11 [verbose debug info unavailable] invalid opcode: 0000 [#1] SMP Modules linked in:
Pid: 70, comm: kasyncinit Not tainted (2.6.27-rc3-tip-00191-g98ccb89-dirty #23)
EIP: 0060:[<40206b11>] EFLAGS: 00010092 CPU: 0
EIP is at do_IRQ+0x6b/0xae
EAX: 00000032 EBX: 00001d28 ECX: 00003434 EDX: 00000046
ESI: 00000000 EDI: 00000059 EBP: c7a37d3c ESP: c7a37d14
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process kasyncinit (pid: 70, ti=c7a36000 task=c79c9860 task.ti=c7a36000)
Stack: 40a74317 40814ea0 ffffffff 00000059 00000000 00000000 ffffffff c421bd20
c7a37d9c c7a37dac c7a37d7c 4020555f c421bd20 00000000 c421bd20 c7a37d9c
c7a37dac c7a37d7c 40b717f8 0000007b 0000007b 000000d8 ffffffa6 4080db6c
Call Trace:
[<4020555f>] ? common_interrupt+0x23/0x28it is on 16cores system with 32bit bigsmp, so it is using phy_flat cpu 5 has apicid 9, and ioapic reg setting right with Dmod= 0 ( phys)
but io_apic controller deliver that interrupt to cpu0 (with apicid =
4) instead of cpu 5 (with apic id = 9)
look at the 64 bit, TARGET_CPUS for phys_flat is cpu_online_map
and 32bit bigsmp TARGET_CPUS is only one cpu set and rotating with online cpu...
Change 32bit bigsmp TARGE_CPUS ?
YH
Quoted 50 lines · Yinghai Lu
find something interesting:
found new
irq_cfgfor irq 20
0add_pin_to_irq: irq 20 --> apic 0 pin 20assign_irq_vector: irq 20 vector0x59cpu 5
IOAPIC[0]: Set routing entry (0-20 ->0x59-> IRQ 20 Mode:1 Active:1) found newirq_descfor irq 20
pci 0000:00:02.1: PCI INT B -> Link[LUS2] -> GSI 20 (level, low) -> IRQ 20IO APIC #0......
.... register #00: 00000000....... : physical APIC id: 00 ....... : Delivery Type: 0 ....... : LTS : 0 .... register #01: 00170011 ....... : max redirection entries: 0017 ....... : PRQ implemented: 0 ....... : IO APIC version: 0011.... register #02: 00000000
....... : arbitration: 00
.... IRQ redirection table:
NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect:
...
14 09 1 1 0 1 0 0 0 59
...
ehci_hcd0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004do_IRQ: cannot handle IRQ -1 vector0x59cpu 0------------[ cut here ]------------ Kernel BUG at 40206b11 [verbose debug info unavailable] invalid opcode: 0000 [#1] SMP Modules linked in:Pid: 70, comm: kasyncinit Not tainted (2.6.27-rc3-tip-00191-g98ccb89-dirty #23)
EIP: 0060:[<40206b11>] EFLAGS: 00010092 CPU: 0
EIP is atdo_IRQ+0x6b/0xae
EAX: 00000032 EBX:00001d28ECX: 00003434 EDX: 00000046
ESI: 00000000 EDI: 00000059 EBP:c7a37d3cESP:c7a37d14
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process kasyncinit (pid: 70, ti=c7a36000 task=c79c9860 task.ti=c7a36000)Stack: 40a74317 40814ea0 ffffffff 00000059 00000000 00000000 ffffffff c421bd20 c7a37d9c c7a37dac c7a37d7c 4020555f c421bd20 00000000 c421bd20 c7a37d9c c7a37dac c7a37d7c 40b717f8 0000007b 0000007b 000000d8 ffffffa6 4080db6c Call Trace: [<4020555f>] ? common_interrupt+0x23/0x28it is on 16cores system with 32bit bigsmp, so it is using
phy_flatcpu 5 has apicid 9, and ioapic reg setting right with Dmod= 0 ( phys)
Quoted 8 lines
but
io_apiccontroller deliver that interrupt to cpu0 (with apicid =
4) instead of cpu 5 (with apic id = 9)look at the 64 bit,
TARGET_CPUSforphys_flatiscpu_online_mapand 32bit bigsmp
TARGET_CPUSis only one cpu set and rotating with online cpu...Change 32bit bigsmp
TARGE_CPUS?
Set vector_allocation_domain to CPU_MASK_ALL on 32bit. That doesn't give us the benefit of per cpu vectors right now, but in my research there has not been a 32bit kernel yet that has needed it. We have never shared vectors between 2 gsi on 32bit x86, we have only collapsed the irq space.
On x86_64 before I did the per cpu vectors there were machines that combined multiple interrupt sources (gsi) into the same irq. So x86_64 has needed the per cpu vectors.
Which means in practice that the irq compression on x86_32 was just a hack to with not having enough irq_desc entries. I wish I had realized that last time we were talking, as we could have unilaterally ripped out all of that code as completely unnecessary on x86 and just bumped NR_IRQS to 1024 on the boxes that had more than 256 gsis.
Eric
Quoted 57 lines · Eric W. Biederman
Quoted 55 lines · Yinghai Lu
find something interesting:
found new
irq_cfgfor irq 20
0add_pin_to_irq: irq 20 --> apic 0 pin 20assign_irq_vector: irq 20 vector0x59cpu 5
IOAPIC[0]: Set routing entry (0-20 ->0x59-> IRQ 20 Mode:1 Active:1) found newirq_descfor irq 20
pci 0000:00:02.1: PCI INT B -> Link[LUS2] -> GSI 20 (level, low) -> IRQ 20IO APIC #0......
.... register #00: 00000000....... : physical APIC id: 00 ....... : Delivery Type: 0 ....... : LTS : 0 .... register #01: 00170011 ....... : max redirection entries: 0017 ....... : PRQ implemented: 0 ....... : IO APIC version: 0011.... register #02: 00000000
....... : arbitration: 00
.... IRQ redirection table:
NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect:
...
14 09 1 1 0 1 0 0 0 59
...
ehci_hcd0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004do_IRQ: cannot handle IRQ -1 vector0x59cpu 0------------[ cut here ]------------ Kernel BUG at 40206b11 [verbose debug info unavailable] invalid opcode: 0000 [#1] SMP Modules linked in:Pid: 70, comm: kasyncinit Not tainted (2.6.27-rc3-tip-00191-g98ccb89-dirty #23)
EIP: 0060:[<40206b11>] EFLAGS: 00010092 CPU: 0
EIP is atdo_IRQ+0x6b/0xae
EAX: 00000032 EBX:00001d28ECX: 00003434 EDX: 00000046
ESI: 00000000 EDI: 00000059 EBP:c7a37d3cESP:c7a37d14
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process kasyncinit (pid: 70, ti=c7a36000 task=c79c9860 task.ti=c7a36000)Stack: 40a74317 40814ea0 ffffffff 00000059 00000000 00000000 ffffffff c421bd20 c7a37d9c c7a37dac c7a37d7c 4020555f c421bd20 00000000 c421bd20 c7a37d9c c7a37dac c7a37d7c 40b717f8 0000007b 0000007b 000000d8 ffffffa6 4080db6c Call Trace: [<4020555f>] ? common_interrupt+0x23/0x28it is on 16cores system with 32bit bigsmp, so it is using
phy_flatcpu 5 has apicid 9, and ioapic reg setting right with Dmod= 0 ( phys)but
io_apiccontroller deliver that interrupt to cpu0 (with apicid =
4) instead of cpu 5 (with apic id = 9)look at the 64 bit,
TARGET_CPUSforphys_flatiscpu_online_map
Quoted 8 lines
Quoted 3 lines
and 32bit bigsmp
TARGET_CPUSis only one cpu set and rotating with online cpu...Change 32bit bigsmp
TARGE_CPUS?Set
vector_allocation_domaintoCPU_MASK_ALLon 32bit. That doesn't give us the benefit of per cpu vectors right now, but in my research there has not been a 32bit kernel yet that has needed it. We have never shared vectors between 2 gsi on 32bit x86, we have only collapsed the irq space.
TARGET_CPUS only used by ioapic_xx.c
vector_allocator_domain will return cpumask_of_cpu(cpu)..
Quoted 10 lines
On
x86_64before I did the per cpu vectors there were machines that combined multiple interrupt sources (gsi) into the same irq. Sox86_64has needed the per cpu vectors.Which means in practice that the irq compression on
x86_32was just a hack to with not having enoughirq_descentries. I wish I had realized that last time we were talking, as we could have unilaterally ripped out all of that code as completely unnecessary on x86 and just bumpedNR_IRQSto 1024 on the boxes that had more than 256 gsis.
now 32bit and 64bit is the same page now... (bigsmp == phys_flat)...
will continue to merge io_apic_xx.c
YH
Quoted 64 lines · Yinghai Lu
Quoted 28 lines · Eric W. Biederman
Quoted 26 lines · Yinghai Lu
find something interesting:
found new
irq_cfgfor irq 20
0add_pin_to_irq: irq 20 --> apic 0 pin 20assign_irq_vector: irq 20 vector0x59cpu 5
IOAPIC[0]: Set routing entry (0-20 ->0x59-> IRQ 20 Mode:1 Active:1) found newirq_descfor irq 20
pci 0000:00:02.1: PCI INT B -> Link[LUS2] -> GSI 20 (level, low) -> IRQ 20IO APIC #0......
.... register #00: 00000000....... : physical APIC id: 00 ....... : Delivery Type: 0 ....... : LTS : 0 .... register #01: 00170011 ....... : max redirection entries: 0017 ....... : PRQ implemented: 0 ....... : IO APIC version: 0011.... register #02: 00000000
....... : arbitration: 00
.... IRQ redirection table:
NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect:
...
14 09 1 1 0 1 0 0 0 59
...Quoted 8 lines
Quoted 8 lines
ehci_hcd0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004do_IRQ: cannot handle IRQ -1 vector0x59cpu 0------------[ cut here ]------------ Kernel BUG at 40206b11 [verbose debug info unavailable] invalid opcode: 0000 [#1] SMP Modules linked in:Pid: 70, comm: kasyncinit Not tainted (2.6.27-rc3-tip-00191-g98ccb89-dirty
#23)
Quoted 7 lines
Quoted 7 lines
EIP: 0060:[<40206b11>] EFLAGS: 00010092 CPU: 0
EIP is atdo_IRQ+0x6b/0xae
EAX: 00000032 EBX:00001d28ECX: 00003434 EDX: 00000046
ESI: 00000000 EDI: 00000059 EBP:c7a37d3cESP:c7a37d14
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process kasyncinit (pid: 70, ti=c7a36000 task=c79c9860 task.ti=c7a36000)Stack: 40a74317 40814ea0 ffffffff 00000059 00000000 00000000 ffffffff
c421bd20Quoted 9 lines
Quoted 9 lines
c7a37d9cc7a37dacc7a37d7c4020555fc421bd2000000000c421bd20c7a37d9cc7a37dacc7a37d7c40b717f80000007b0000007b000000d8ffffffa64080db6cCall Trace: [<4020555f>] ? common_interrupt+0x23/0x28it is on 16cores system with 32bit bigsmp, so it is using
phy_flatcpu 5 has apicid 9, and ioapic reg setting right with Dmod= 0 ( phys)Quoted 6 lines
Quoted 6 lines
but
io_apiccontroller deliver that interrupt to cpu0 (with apicid =
4) instead of cpu 5 (with apic id = 9)look at the 64 bit,
TARGET_CPUSforphys_flatiscpu_online_mapand 32bit bigsmp
TARGET_CPUSis only one cpu set and rotating with onlinecpu...
Quoted 1 line
Quoted 1 line
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
Change 32bit bigsmp
TARGE_CPUS?Set
vector_allocation_domaintoCPU_MASK_ALLon 32bit. That doesn't give us the benefit of per cpu vectors right now, but in my research there has not been a 32bit kernel yet that has needed it. We have never shared vectors between 2 gsi on 32bit x86, we have only collapsed the irq space.
TARGET_CPUSonly used byioapic_xx.c
Target cpus is a hint to tell us what to do if the user has not.
Quoted 1 line
vector_allocator_domainwill returncpumask_of_cpu(cpu)..
Which is a bug for lowest priority delivery mode. But you said phys_flat and not flat. Which sounds like bigsmp last I read it.
Quoted 10 lines
Quoted 9 lines
On
x86_64before I did the per cpu vectors there were machines that combined multiple interrupt sources (gsi) into the same irq. Sox86_64has needed the per cpu vectors.Which means in practice that the irq compression on
x86_32was just a hack to with not having enoughirq_descentries. I wish I had realized that last time we were talking, as we could have unilaterally ripped out all of that code as completely unnecessary on x86 and just bumpedNR_IRQSto 1024 on the boxes that had more than 256 gsis.
Quoted 3 lines
now 32bit and 64bit is the same page now... (bigsmp ==
phys_flat)...will continue to merge
io_apic_xx.c
Hmm. In that case I will ask that you look at all of the pieces of irq migration code, and make certain that they have all come from x86_64.
There were a lot of little changes that had to be made. If this is an irq migration problem it should be easy to find, by stressing irq migration in user space. You probably want to turn off the in kernel irq balancer while debugging this.
Eric
Quoted 92 lines · Eric W. Biederman
Quoted 64 lines · Yinghai Lu
Quoted 28 lines · Eric W. Biederman
Quoted 26 lines · Yinghai Lu
find something interesting:
found new
irq_cfgfor irq 20
0add_pin_to_irq: irq 20 --> apic 0 pin 20assign_irq_vector: irq 20 vector0x59cpu 5
IOAPIC[0]: Set routing entry (0-20 ->0x59-> IRQ 20 Mode:1 Active:1) found newirq_descfor irq 20
pci 0000:00:02.1: PCI INT B -> Link[LUS2] -> GSI 20 (level, low) -> IRQ 20IO APIC #0......
.... register #00: 00000000....... : physical APIC id: 00 ....... : Delivery Type: 0 ....... : LTS : 0 .... register #01: 00170011 ....... : max redirection entries: 0017 ....... : PRQ implemented: 0 ....... : IO APIC version: 0011.... register #02: 00000000
....... : arbitration: 00
.... IRQ redirection table:
NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect:
...
14 09 1 1 0 1 0 0 0 59
...Quoted 8 lines
Quoted 8 lines
ehci_hcd0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004do_IRQ: cannot handle IRQ -1 vector0x59cpu 0------------[ cut here ]------------ Kernel BUG at 40206b11 [verbose debug info unavailable] invalid opcode: 0000 [#1] SMP Modules linked in:Pid: 70, comm: kasyncinit Not tainted (2.6.27-rc3-tip-00191-g98ccb89-dirty
#23)
Quoted 7 lines
Quoted 7 lines
EIP: 0060:[<40206b11>] EFLAGS: 00010092 CPU: 0
EIP is atdo_IRQ+0x6b/0xae
EAX: 00000032 EBX:00001d28ECX: 00003434 EDX: 00000046
ESI: 00000000 EDI: 00000059 EBP:c7a37d3cESP:c7a37d14
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process kasyncinit (pid: 70, ti=c7a36000 task=c79c9860 task.ti=c7a36000)Stack: 40a74317 40814ea0 ffffffff 00000059 00000000 00000000 ffffffff
c421bd20Quoted 9 lines
Quoted 9 lines
c7a37d9cc7a37dacc7a37d7c4020555fc421bd2000000000c421bd20c7a37d9cc7a37dacc7a37d7c40b717f80000007b0000007b000000d8ffffffa64080db6cCall Trace: [<4020555f>] ? common_interrupt+0x23/0x28it is on 16cores system with 32bit bigsmp, so it is using
phy_flatcpu 5 has apicid 9, and ioapic reg setting right with Dmod= 0 ( phys)Quoted 6 lines
Quoted 6 lines
but
io_apiccontroller deliver that interrupt to cpu0 (with apicid =
4) instead of cpu 5 (with apic id = 9)look at the 64 bit,
TARGET_CPUSforphys_flatiscpu_online_mapand 32bit bigsmp
TARGET_CPUSis only one cpu set and rotating with onlinecpu...
Quoted 1 line
Quoted 1 line
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
Change 32bit bigsmp
TARGE_CPUS?Set
vector_allocation_domaintoCPU_MASK_ALLon 32bit. That doesn't give us the benefit of per cpu vectors right now, but in my research there has not been a 32bit kernel yet that has needed it. We have never shared vectors between 2 gsi on 32bit x86, we have only collapsed the irq space.
TARGET_CPUSonly used byioapic_xx.cTarget cpus is a hint to tell us what to do if the user has not.
Quoted 1 line
vector_allocator_domainwill returncpumask_of_cpu(cpu)..Which is a bug for lowest priority delivery mode. But you said
phys_flatand not flat. Which sounds like bigsmp last I read it.Quoted 10 lines
Quoted 9 lines
On
x86_64before I did the per cpu vectors there were machines that combined multiple interrupt sources (gsi) into the same irq. Sox86_64has needed the per cpu vectors.Which means in practice that the irq compression on
x86_32was just a hack to with not having enoughirq_descentries. I wish I had realized that last time we were talking, as we could have unilaterally ripped out all of that code as completely unnecessary on x86 and just bumpedNR_IRQSto 1024 on the boxes that had more than 256 gsis.
Quoted 6 lines
Quoted 3 lines
now 32bit and 64bit is the same page now... (bigsmp ==
phys_flat)...will continue to merge
io_apic_xx.cHmm. In that case I will ask that you look at all of the pieces of irq migration code, and make certain that they have all come from
x86_64.
yes, done. now it is same as 64 bit.
YH
Quoted 1 line · Yinghai Lu
yes, done. now it is same as 64 bit.
Cool. I'm now off until monday. Hopefully I can post some patches and we can have a good debate then.
Eric
Quoted 66 lines · Yinghai Lu
Quoted 28 lines · Eric W. Biederman
Quoted 26 lines · Yinghai Lu
find something interesting:
found new
irq_cfgfor irq 20
0add_pin_to_irq: irq 20 --> apic 0 pin 20assign_irq_vector: irq 20 vector0x59cpu 5
IOAPIC[0]: Set routing entry (0-20 ->0x59-> IRQ 20 Mode:1 Active:1) found newirq_descfor irq 20
pci 0000:00:02.1: PCI INT B -> Link[LUS2] -> GSI 20 (level, low) -> IRQ 20IO APIC #0......
.... register #00: 00000000....... : physical APIC id: 00 ....... : Delivery Type: 0 ....... : LTS : 0 .... register #01: 00170011 ....... : max redirection entries: 0017 ....... : PRQ implemented: 0 ....... : IO APIC version: 0011.... register #02: 00000000
....... : arbitration: 00
.... IRQ redirection table:
NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect:
...
14 09 1 1 0 1 0 0 0 59
...Quoted 8 lines
Quoted 8 lines
ehci_hcd0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004do_IRQ: cannot handle IRQ -1 vector0x59cpu 0------------[ cut here ]------------ Kernel BUG at 40206b11 [verbose debug info unavailable] invalid opcode: 0000 [#1] SMP Modules linked in:Pid: 70, comm: kasyncinit Not tainted (2.6.27-rc3-tip-00191-g98ccb89-dirty
#23)
Quoted 7 lines
Quoted 7 lines
EIP: 0060:[<40206b11>] EFLAGS: 00010092 CPU: 0
EIP is atdo_IRQ+0x6b/0xae
EAX: 00000032 EBX:00001d28ECX: 00003434 EDX: 00000046
ESI: 00000000 EDI: 00000059 EBP:c7a37d3cESP:c7a37d14
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process kasyncinit (pid: 70, ti=c7a36000 task=c79c9860 task.ti=c7a36000)Stack: 40a74317 40814ea0 ffffffff 00000059 00000000 00000000 ffffffff
c421bd20Quoted 9 lines
Quoted 9 lines
c7a37d9cc7a37dacc7a37d7c4020555fc421bd2000000000c421bd20c7a37d9cc7a37dacc7a37d7c40b717f80000007b0000007b000000d8ffffffa64080db6cCall Trace: [<4020555f>] ? common_interrupt+0x23/0x28it is on 16cores system with 32bit bigsmp, so it is using
phy_flatcpu 5 has apicid 9, and ioapic reg setting right with Dmod= 0 ( phys)Quoted 6 lines
Quoted 6 lines
but
io_apiccontroller deliver that interrupt to cpu0 (with apicid =
4) instead of cpu 5 (with apic id = 9)look at the 64 bit,
TARGET_CPUSforphys_flatiscpu_online_mapand 32bit bigsmp
TARGET_CPUSis only one cpu set and rotating with onlinecpu...
Quoted 3 lines
Quoted 2 lines
Change 32bit bigsmp
TARGE_CPUS?
Quoted 8 lines
Quoted 4 lines
Set
vector_allocation_domaintoCPU_MASK_ALLon 32bit. That doesn't give us the benefit of per cpu vectors right now, but in my research there has not been a 32bit kernel yet that has needed it. We have never shared vectors between 2 gsi on 32bit x86, we have only collapsed the irq space.
TARGET_CPUSonly used byioapic_xx.c
vector_allocator_domainwill returncpumask_of_cpu(cpu)..
Note: Only vector_allocation_domain matters. That is where we setup the irq to be received. TARGET_CPUS is just a request to send the irq to someplace in that mask.
Eric
Quoted 16 lines · Yinghai Lu
On Thu, Aug 14, 2008 at 1:05 PM, Eric W. Biederman
Quoted 5 lines
What I wound up using in my tree is a little different.
I introduced an opaque/empty structure: struct irq to be used in places where we need pointers instead of an integer irq number in the interfaces.
Quoted 7 lines
I have a version of the genirq api that works on struct irq instead of unsigned int irq.
I have functions:
struct irq *to_irq(unsigned int nr);
structirq_desc*to_idesc(struct irq *);
unsigned intirq_nr(struct irq *irq);
Quoted 4 lines
struct irq {
unsigned int nr;
structirq_desc*idesc;
}
I did:
struct irq_desc {
struct irq irq;
.... }
Then to_idesc is just a container_of call. Or simply a type cast but that is rude.
Having nr be a field in struct irq is possibly valid.
When last we talked about the design Linus was emphatic that what gets exposed to drivers be an opaque token. When I looked for 99%+ of the arch code we can use that same opaque token. irq_desc is something we don't really care about except in do_IRQ().
So I guess the truly important thing is that struct irq is not ultimately available in a usable form to drivers.
We seem to give drivers access to everything when they include interrupt.h So I'm not certain how strict we can succeed in being still is a good goal to aim for.
Quoted 11 lines
Quoted 10 lines
Is there any reason why the migration path for architectures can not be:
Until they are converted:
#defineNR_IRQSand use theirq_descarray.If they are just using a dynamically allocated array. #define
NR_IRQSnr_irqsOnce we kill the array entirely.
#undefNR_IRQSor
#defineNR_IRQS0xfffff000why not use -1U here?
So that negative error codes continue not to be valid irqs.
In most places irq is an unsigned int so it may safely be used to index irq_desc. In other paces people are sloppier and used a signed value so they can return
negative error values. create_irq() on x86 is one of those places. There
is also platform_get_irq. and possibly a few others.
Eric
Quoted 10 lines · Yinghai Lu
Quoted 6 lines
A couple of observations about the general structure of the sparse irqs code:
- the new APIs should probably live in
mm/bootmem.cnot ininit/main.c, and inbootmem.h. Also, it should be outlined clearly why this new API is needed as a wrapper ontop of existing bootmem mechanisms.move
pre_alloc_dyn_array,per_cpu_dyn_array_size,per_cpu_alloc_dyn_arraytomm/bootmem.c?
yeah, i think so. It's an "even earlier than bootmem" bootmem allocator.
Quoted 51 lines
Quoted 4 lines
- the #ifdef complications, while fine for migration, should be eliminated. Could we introduce some compatible form for the definition/allocation APIs that work even if an architecture still uses a flat irq array? That would remove most of the uglinesses.
# git grep CONFIG_HAVE_DYN_ARRAY | wc -l 9#git grep
CONFIG_HAVE_SPARSE_IRQ| wc -l
39arch/x86/kernel/io_apic_32.c:#ifdef
CONFIG_HAVE_SPARSE_IRQ_DEBUGarch/x86/kernel/io_apic_32.c:#ifndefCONFIG_HAVE_SPARSE_IRQarch/x86/kernel/io_apic_64.c:#ifdefCONFIG_HAVE_SPARSE_IRQ_DEBUGarch/x86/kernel/io_apic_64.c:#ifndefCONFIG_HAVE_SPARSE_IRQarch/x86/kernel/irq_32.c:#ifdefCONFIG_HAVE_SPARSE_IRQarch/x86/kernel/irq_64.c:#ifdefCONFIG_HAVE_SPARSE_IRQdrivers/char/random.c:#ifndefCONFIG_HAVE_SPARSE_IRQdrivers/char/random.c:#ifndefCONFIG_HAVE_SPARSE_IRQdrivers/pci/intr_remapping.c:#ifdefCONFIG_HAVE_SPARSE_IRQdrivers/pci/intr_remapping.c:#else /* !CONFIG_HAVE_SPARSE_IRQ */
drivers/pci/intr_remapping.c:#ifndefCONFIG_HAVE_SPARSE_IRQ
fs/proc/proc_misc.c:#ifdefCONFIG_HAVE_SPARSE_IRQfs/proc/proc_misc.c:#ifdefCONFIG_HAVE_SPARSE_IRQfs/proc/proc_misc.c:#ifdefCONFIG_HAVE_SPARSE_IRQinclude/linux/irq.h:#ifdefCONFIG_HAVE_SPARSE_IRQinclude/linux/irq.h:#ifdefCONFIG_HAVE_SPARSE_IRQinclude/linux/irq.h:#ifdefCONFIG_HAVE_SPARSE_IRQinclude/linux/irq.h:#ifdefCONFIG_HAVE_SPARSE_IRQinclude/linux/irq.h:#ifdefined(CONFIG_INTR_REMAP)&&defined(CONFIG_HAVE_SPARSE_IRQ)include/linux/irq.h:#ifndefCONFIG_HAVE_SPARSE_IRQkernel/irq/chip.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/chip.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/chip.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/chip.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/chip.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifndefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQ_DEBUGkernel/irq/handle.c:#ifndefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/handle.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/manage.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/manage.c:#ifdefCONFIG_HAVE_SPARSE_IRQkernel/irq/migration.c:#ifdefCONFIG_HAVE_SPARSE_IRQ
Quoted 1 line
because try to avoid more api to be changed to take
irq_descas parameter.
yes - but in the end we should remove all the #ifdefs and try to hide them away into include file driven abstractions.
Quoted 4 lines
Quoted 2 lines
- some of the irq < 16 checks in x86 look a bit ugly, can we do anything about them?
is_legacy_irq(irq)? orlegacy_irq(irq)?
legacy_irq(irq) sounds like the right name to me.
Quoted 7 lines
Quoted 4 lines
- i think as a final-ish commit we should just remove the dyn-array define and make all architectures use this facility. You converted most of them - how many are still missing? Sparse-irq is more intrusive so that should probably stay a
Kconfigknob.so when
config_sparse_irqis not selected, need to usedyn_arrayto allocateirq_descandirq_cfg, or just static array?
well in the worst case just static array - but lets use the same APIs on them in .c files.
i.e. we can make this all gradual and compatible - and we can allow dual use of old-style irq_desc[] _and_ the new APIs in the same kernel even (so that old architectures will work just fine, even if not touched) - but he tons of #ifdefs are ugly.
Quoted 11 lines
Quoted 7 lines
- there was one aspect of
NR_IRQSthat was nice and useful: it acted as a sanity check against BIOS bugs and driver bugs that pass in some irrealistically high irq number. Now we'll just try to allocate some really high IRQ and accept it. I _think_ there should be a single, simple 'absolute maximum IRQ number' define which should set the maximum possible IRQ number. Lets call itNR_IRQS_MAXor so, and set it to NR_CPUS*NR_IO_APICS*224 or so?when
sparse_irqis used, irq is [0, -1U]
driver could beirq_desc(irq)to check if irq is valid or not. and useirq_desc_with_new(new)to get a new one.
ok. The suggestion from Eric is still valid, to use 0xffff0000, to exclude small negative numbers. (so that a driver does not accidentally pass a -EINVAL or -ENODEV into request_irq() or so)
Quoted 2 lines
when
generic_hardirqsis not used (s390, m68k, sparc), we need to create some stubs inlinux/interrupt.hfor them
ok.
Quoted 24 lines
Quoted 8 lines
- i'm a bit worried about linecount increase in general:
247 files changed, 3671 insertions(+), 2052 deletions(-)could we work on reducing that somewhat? The new infrastructure bits in
mm/*andkernel/irq/*will be unavoidable, what we should concentrate on is to make usage of the new facility just as straightforward, easy and compact as the old irq_desc[] usages.before that we could use
get_irq_desc()andget_irq_desc_without_new()and according to eric, i changed that toirq_desc_with_newandirq_desc().so the array irq_desc[] need to be changed to irq_descX[] ( or
*irq_descto*irq_descXfordyn_array)Quoted 7 lines
A worst-case example is
drivers/char/random.c: theCONFIG_HAVE_SPARSE_IRQandCONFIG_HAVE_DYN_ARRAY#ifdef jungle is not acceptable. I think the best way out is to convert the whole kernel to the new facilities (as safely as possible, without breaking other architectures), and making sure that the end result is easy to understand and intuitive.
Quoted 6 lines
# grep CONFIG_HAVE_ drivers/char/random.c #ifndef CONFIG_HAVE_SPARSE_IRQ #ifdef CONFIG_HAVE_DYN_ARRAY #ifndef CONFIG_HAVE_SPARSE_IRQjust want to make other arch is untouched.
that should still be the case - untouched architectures should continue to work - but cannot we just wrap it all for them so that the new APIs will simply access the static, non-sparse irq_desc[] array that those old architectures presume exist?
Ingo
Quoted 1 line · On Thu, 14 Aug 2008 15:26:38 +0200 Ingo Molnar <[email protected]> wrote:
ok, i've created a new tip/irq/sparseirq topic branch for this.
This:
init/dyn_array.c: In function 'pre_alloc_dyn_array':init/dyn_array.c:21: warning: 'print_fn_descriptor_symbol' is deprecated (declared at include/linux/kallsyms.h:100) init/dyn_array.c:45: warning: 'print_fn_descriptor_symbol' is deprecated (declared at include/linux/kallsyms.h:100) init/dyn_array.c: In function 'per_cpu_dyn_array_size':init/dyn_array.c:78: warning: 'print_fn_descriptor_symbol' is deprecated (declared at include/linux/kallsyms.h:100) init/dyn_array.c: In function 'per_cpu_alloc_dyn_array':init/dyn_array.c:107: warning: 'print_fn_descriptor_symbol' is deprecated (declared at include/linux/kallsyms.h:100)
is reminding us about %pS/%pF.
Quoted 15 lines · Andrew Morton
Quoted 1 line · On Thu, 14 Aug 2008 15:26:38 +0200 Ingo Molnar <[email protected]> wrote:
ok, i've created a new tip/irq/sparseirq topic branch for this.
This:
init/dyn_array.c: In function 'pre_alloc_dyn_array':init/dyn_array.c:21: warning: 'print_fn_descriptor_symbol' is deprecated (declared atinclude/linux/kallsyms.h:100)init/dyn_array.c:45: warning: 'print_fn_descriptor_symbol' is deprecated (declared atinclude/linux/kallsyms.h:100)init/dyn_array.c: In function 'per_cpu_dyn_array_size':init/dyn_array.c:78: warning: 'print_fn_descriptor_symbol' is deprecated (declared atinclude/linux/kallsyms.h:100)init/dyn_array.c: In function 'per_cpu_alloc_dyn_array':init/dyn_array.c:107: warning: 'print_fn_descriptor_symbol' is deprecated (declared atinclude/linux/kallsyms.h:100)
Quoted 1 line
is reminding us about %pS/%pF.
in init/main.c::do_one_initcall() is still using it...
also i didn't get this warning, what is your gcc version?
YH
Quoted 17 lines · On Fri, 29 Aug 2008 14:43:45 -0700 "Yinghai Lu" <[email protected]> wrote:
Quoted 15 lines · Andrew Morton
Quoted 1 line · On Thu, 14 Aug 2008 15:26:38 +0200 Ingo Molnar <[email protected]> wrote:
ok, i've created a new tip/irq/sparseirq topic branch for this.
This:
init/dyn_array.c: In function 'pre_alloc_dyn_array':init/dyn_array.c:21: warning: 'print_fn_descriptor_symbol' is deprecated (declared atinclude/linux/kallsyms.h:100)init/dyn_array.c:45: warning: 'print_fn_descriptor_symbol' is deprecated (declared atinclude/linux/kallsyms.h:100)init/dyn_array.c: In function 'per_cpu_dyn_array_size':init/dyn_array.c:78: warning: 'print_fn_descriptor_symbol' is deprecated (declared atinclude/linux/kallsyms.h:100)init/dyn_array.c: In function 'per_cpu_alloc_dyn_array':init/dyn_array.c:107: warning: 'print_fn_descriptor_symbol' is deprecated (declared atinclude/linux/kallsyms.h:100)
Quoted 3 lines
Quoted 1 line
is reminding us about %pS/%pF.
in init/main.c::do_one_initcall() is still using it...
So?
That got converted in -mm.
Quoted 1 line
also i didn't get this warning, what is your gcc version?
Quoted 24 lines · Andrew Morton
Quoted 17 lines · On Fri, 29 Aug 2008 14:43:45 -0700 "Yinghai Lu" <[email protected]> wrote:
Quoted 15 lines · Andrew Morton
Quoted 1 line · On Thu, 14 Aug 2008 15:26:38 +0200 Ingo Molnar <[email protected]> wrote:
ok, i've created a new tip/irq/sparseirq topic branch for this.
This:
init/dyn_array.c: In function 'pre_alloc_dyn_array':init/dyn_array.c:21: warning: 'print_fn_descriptor_symbol' is deprecated (declared atinclude/linux/kallsyms.h:100)init/dyn_array.c:45: warning: 'print_fn_descriptor_symbol' is deprecated (declared atinclude/linux/kallsyms.h:100)init/dyn_array.c: In function 'per_cpu_dyn_array_size':init/dyn_array.c:78: warning: 'print_fn_descriptor_symbol' is deprecated (declared atinclude/linux/kallsyms.h:100)init/dyn_array.c: In function 'per_cpu_alloc_dyn_array':init/dyn_array.c:107: warning: 'print_fn_descriptor_symbol' is deprecated (declared atinclude/linux/kallsyms.h:100)Quoted 3 lines
Quoted 1 line
is reminding us about %pS/%pF.
in init/main.c::do_one_initcall() is still using it...
Quoted 7 lines
So?
That got converted in -mm.
Quoted 1 line
also i didn't get this warning, what is your gcc version?
thanks
will send one patch to you
YH