[patch] genirq: do not mask interrupts by default

[patch] genirq: do not mask interrupts by default

[Ingo Molnar]

Subject: [patch] genirq: do not mask interrupts by default
From: Ingo Molnar <mingo@elte.hu>

never mask interrupts immediately upon request. Disabling interrupts in 
high-performance codepaths is rare, and on the other hand this change 
could recover lost edges (or even other types of lost interrupts) by 
conservatively only masking interrupts after they happen. (NOTE: with 
this change the highlevel irq-disable code still soft-disables this IRQ 
line - and if such an interrupt happens then the IRQ flow handler keeps 
the IRQ masked.)

mark i8529A controllers as 'never loses an edge'.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/i386/kernel/i8259.c   |    1 +
 arch/x86_64/kernel/i8259.c |    1 +
 kernel/irq/chip.c          |   17 ++++++++++-------
 3 files changed, 12 insertions(+), 7 deletions(-)

Index: linux/arch/i386/kernel/i8259.c
===================================================================
--- linux.orig/arch/i386/kernel/i8259.c
+++ linux/arch/i386/kernel/i8259.c
@@ -41,6 +41,7 @@ static void mask_and_ack_8259A(unsigned 
 static struct irq_chip i8259A_chip = {
 	.name		= "XT-PIC",
 	.mask		= disable_8259A_irq,
+	.disable	= disable_8259A_irq,
 	.unmask		= enable_8259A_irq,
 	.mask_ack	= mask_and_ack_8259A,
 };
Index: linux/arch/x86_64/kernel/i8259.c
===================================================================
--- linux.orig/arch/x86_64/kernel/i8259.c
+++ linux/arch/x86_64/kernel/i8259.c
@@ -103,6 +103,7 @@ static void mask_and_ack_8259A(unsigned 
 static struct irq_chip i8259A_chip = {
 	.name		= "XT-PIC",
 	.mask		= disable_8259A_irq,
+	.disable	= disable_8259A_irq,
 	.unmask		= enable_8259A_irq,
 	.mask_ack	= mask_and_ack_8259A,
 };
Index: linux/kernel/irq/chip.c
===================================================================
--- linux.orig/kernel/irq/chip.c
+++ linux/kernel/irq/chip.c
@@ -202,10 +202,6 @@ static void default_enable(unsigned int 
  */
 static void default_disable(unsigned int irq)
 {
-	struct irq_desc *desc = irq_desc + irq;
-
-	if (!(desc->status & IRQ_DELAYED_DISABLE))
-		desc->chip->mask(irq);
 }
 
 /*
@@ -270,13 +266,18 @@ handle_simple_irq(unsigned int irq, stru
 
 	if (unlikely(desc->status & IRQ_INPROGRESS))
 		goto out_unlock;
-	desc->status &= ~(IRQ_REPLAY | IRQ_WAITING);
 	kstat_cpu(cpu).irqs[irq]++;
 
 	action = desc->action;
-	if (unlikely(!action || (desc->status & IRQ_DISABLED)))
+	if (unlikely(!action || (desc->status & IRQ_DISABLED))) {
+		if (desc->chip->mask)
+			desc->chip->mask(irq);
+		desc->status &= ~(IRQ_REPLAY | IRQ_WAITING);
+		desc->status |= IRQ_PENDING;
 		goto out_unlock;
+	}
 
+	desc->status &= ~(IRQ_REPLAY | IRQ_WAITING | IRQ_PENDING);
 	desc->status |= IRQ_INPROGRESS;
 	spin_unlock(&desc->lock);
 
@@ -368,11 +369,13 @@ handle_fasteoi_irq(unsigned int irq, str
 
 	/*
 	 * If its disabled or no action available
-	 * keep it masked and get out of here
+	 * then mask it and get out of here:
 	 */
 	action = desc->action;
 	if (unlikely(!action || (desc->status & IRQ_DISABLED))) {
 		desc->status |= IRQ_PENDING;
+		if (desc->chip->mask)
+			desc->chip->mask(irq);
 		goto out;
 	}

----- End forwarded message -----

Re: [PATCH] genirq: do not mask interrupts by default

[Benjamin Herrenschmidt]

On Fri, 2007-02-16 at 17:59 +0000, Linux Kernel Mailing List wrote:
> Gitweb:     http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=76d2160147f43f982dfe881404cfde9fd0a9da21
> Commit:     76d2160147f43f982dfe881404cfde9fd0a9da21
> Parent:     1f2ea0837dbc263ce2a2512c4e73c83df68a6a55
> Author:     Ingo Molnar <mingo@elte.hu>
> AuthorDate: Fri Feb 16 01:28:24 2007 -0800
> Committer:  Linus Torvalds <torvalds@woody.linux-foundation.org>
> CommitDate: Fri Feb 16 08:14:00 2007 -0800
> 
>     [PATCH] genirq: do not mask interrupts by default
>     
>     Never mask interrupts immediately upon request.  Disabling interrupts in
>     high-performance codepaths is rare, and on the other hand this change could
>     recover lost edges (or even other types of lost interrupts) by conservatively
>     only masking interrupts after they happen.  (NOTE: with this change the
>     highlevel irq-disable code still soft-disables this IRQ line - and if such an
>     interrupt happens then the IRQ flow handler keeps the IRQ masked.)
>     
>     Mark i8529A controllers as 'never loses an edge'.

I missed that one ... thanks for not telling/CC'ing me and not fixing
powerpc :-( (I know, everybody is supposed to have the bandwidth to read
all of lkml... I don't).

We need to audit all of our PICs to make sure they can deal with
disabling an already ack'ed interrupt, which isn't clear.. in fact, that
might cause some to lose it when re-enabling later on. This is a major
semantic change and now I just discover it while we are at -rc5 !

I'm concerned that quite a few PICs will not re-emit the interrupt once
re-enabled.

Ben.

Re: [PATCH] genirq: do not mask interrupts by default

[Benjamin Herrenschmidt]

> I missed that one ... thanks for not telling/CC'ing me and not fixing
> powerpc :-( (I know, everybody is supposed to have the bandwidth to read
> all of lkml... I don't).
> 
> We need to audit all of our PICs to make sure they can deal with
> disabling an already ack'ed interrupt, which isn't clear.. in fact, that
> might cause some to lose it when re-enabling later on. This is a major
> semantic change and now I just discover it while we are at -rc5 !
> 
> I'm concerned that quite a few PICs will not re-emit the interrupt once
> re-enabled.

Note that I'm not opposed to the change at all, I think it's a good
idea, I'm just worried I'm discovering it a bit late and I've seen PICs
broken in some many colorful ways that I'm a bit worried... Oh well...

Ben.

Re: [PATCH] genirq: do not mask interrupts by default

[Ingo Molnar]

* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> Note that I'm not opposed to the change at all, I think it's a good 
> idea, I'm just worried I'm discovering it a bit late and I've seen 
> PICs broken in some many colorful ways that I'm a bit worried... Oh 
> well...

This change does not really change irq-flow semantics, what it does is 
that disable_irq()'s effect is delayed. The irq controller does not have 
to re-assert the irq, we've got the soft-resend mechanism. What am i 
missing? Are you worried about this change causing actual breakage? (and 
i'm sorry about not having Cc:-ed you explicitly, i could have sworn you 
were included in that discussion but apparently not!)

	Ingo

Re: [PATCH] genirq: do not mask interrupts by default

[Benjamin Herrenschmidt]

On Tue, 2007-03-27 at 09:32 +0200, Ingo Molnar wrote:
> * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
> > Note that I'm not opposed to the change at all, I think it's a good 
> > idea, I'm just worried I'm discovering it a bit late and I've seen 
> > PICs broken in some many colorful ways that I'm a bit worried... Oh 
> > well...
> 
> This change does not really change irq-flow semantics, what it does is 
> that disable_irq()'s effect is delayed. The irq controller does not have 
> to re-assert the irq, we've got the soft-resend mechanism. What am i 
> missing? Are you worried about this change causing actual breakage? (and 
> i'm sorry about not having Cc:-ed you explicitly, i could have sworn you 
> were included in that discussion but apparently not!)

I'm worried about some broken controllers I know of that might indeed
swallow the interrupt if it occurs, we ack it, then disable it, and
later on re-enable it...

I think the main case I have in mind (pmac-pic) has the necessary
retrigger all over the place but there is definitely a change in the
flow of disabling/enabling here.

Anyway, I'll run some tests tomorrow and make noise if I find something
broken, though I can't test the various embedded thingies in
arch/powerpc.

Ben.

Linux 2.6.19-rc5

[Linus Torvalds]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 16204 bytes --]


Ok, things are finally calming down, it seems.

The -rc5 thing is mainly a few random architecture updates (arm, mips, 
uml, avr, power) and the only really noticeable one there is likely some 
fixes to the local APIC accesses on x86, which apparently fixes a few 
machines.

The rest is really mostly one-liners (or close) to various subsystems. New 
PCI ID's, trivial fixes, cifs, dvb, things like that. I'm feeling better 
about this - there may be a -rc6, but maybe we don't even need one.

As usual, thanks to everybody who tested and chased down some of the 
regressions,

		Linus

---
Adrian Bunk (2):
      [TIPC] net/tipc/port.c: fix NULL dereference
      PCI: Let PCI_MULTITHREAD_PROBE depend on BROKEN

Akinobu Mita (4):
      tokenring: fix module_init error handling
      n2: fix confusing error code
      edac_mc: fix error handling
      sunrpc: add missing spin_unlock

Al Viro (8):
      [IPV6]: File the fingerprints off ah6->spi/esp6->spi
      [IPX]: Trivial parts of endianness annotations
      [IPX]: Annotate and fix IPX checksum
      [IPV6]: Fix ECN bug on big-endian
      [NETFILTER] bug: NFULA_CFG_QTHRESH uses 32bit
      [NETFILTER] bug: nfulnl_msg_config_mode ->copy_range is 32bit
      [NETFILTER] bug: skb->protocol is already net-endian
      [PKTGEN]: TCI endianness fixes

Alexey Dobriyan (1):
      [GFS2] don't panic needlessly

Amol Lad (1):
      drivers/isdn/hysdn/hysdn_sched.c: sleep after taking spinlock fix

Andreas Gruenbacher (1):
      Fix user.* xattr permission check for sticky dirs

Andrew Morton (6):
      find_bd_holder() fix
      tidy "md: check bio address after mapping through partitions"
      Add printk_timed_ratelimit()
      schedule removal of FUTEX_FD
      acpi_noirq section fix
      spi section fix

Andy Fleming (2):
      [POWERPC] Fix rmb() for e500-based machines it
      [POWERPC] Fix oprofile support for e500 in arch/powerpc

Ankita Garg (1):
      Fix for LKDTM MEM_SWAPOUT crashpoint

Atsushi Nemoto (2):
      [MIPS] Fixup migration to GENERIC_TIME
      [MIPS] Do not use -msym32 option for modules.

Auke Kok (1):
      e1000: Fix regression: garbled stats and irq allocation during swsusp

Ben Dooks (5):
      [ARM] 3915/1: S3C2412: Add s3c2410_gpio_getirq() to general gpio.c
      [ARM] 3920/1: S3C24XX: Remove smdk2410_defconfig
      [ARM] 3921/1: S3C24XX: remove bast_defconfig
      [ARM] 3922/1: S3C24XX: update s3c2410_defconfig to 2.6.19-rc4
      [ARM] 3923/1: S3C24XX: update s3c2410_defconfig with new drivers

Benjamin Herrenschmidt (2):
      [POWERPC] Fix various offb issues
      [POWERPC] Make alignment exception always check exception table

Bjorn Schneider (1):
      USB: new VID/PID-combos for cp2101

Brice Goglin (1):
      myri10ge: ServerWorks HT2000 PCI id is already defined in pci_ids.h

Daniel Drake (1):
      jfs: Add splice support

Daniel Ritz (1):
      usbtouchscreen: use endpoint address from endpoint descriptor

Daniel Yeisley (1):
      init_reap_node() initialization fix

Dave Kleikamp (1):
      JFS: Remove redundant xattr permission checking

David Brownell (3):
      USB: fix compiler issues with newer gcc versions
      USB: use MII hooks only if CONFIG_MII is enabled
      [ARM] 3926/1: make timer led handle HZ != 100

David Härdeman (1):
      V4L/DVB (4785): Budget-ci: Change DEBIADDR_IR to a safer default

David Rientjes (1):
      net s2io: return on NULL dev_alloc_skb()

David S. Miller (7):
      [APPLETALK]: Fix potential OOPS in atalk_sendmsg().
      [XFRM] xfrm_user: Fix unaligned accesses.
      [ETH1394]: Fix unaligned accesses.
      [SPARC64]: Fix Tomatillo/Schizo IRQ handling.
      [SPARC64]: Add some missing print_symbol() calls.
      [SPARC64]: Fix futex_atomic_cmpxchg_inatomic implementation.
      [SPARC]: Fix robust futex syscalls and wire up migrate_pages.

Dmitry Mishin (3):
      [NETFILTER]: Missed and reordered checks in {arp,ip,ip6}_tables
      [NETFILTER]: ip_tables: compat code module refcounting fix
      [IPV6]: Add ndisc_netdev_notifier unregister.

Dominic Cerquetti (1):
      USB: xpad: additional USB id's added

Enrico Scholz (1):
      [ARM] 3919/1: Fixed definition of some PXA270 CIF related registers

Erez Zilber (1):
      IB/iser: Start connection after enabling iSER

Eric Sandeen (1):
      fix UFS superblock alignment issues

Eric W. Biederman (3):
      Improve the removed sysctl warnings
      sysctl: allow a zero ctl_name in the middle of a sysctl table
      sysctl: implement CTL_UNNUMBERED

Gautham R Shenoy (1):
      Fix the spurious unlock_cpu_hotplug false warnings

Grant Grundler (1):
      hid-core: big-endian fix fix

Greg Kroah-Hartman (2):
      PCI: Revert "PCI: i386/x86_84: disable PCI resource decode on device disable"
      USB: add another sierra wireless device id

Gui,Jian (1):
      [POWERPC] Disallow kprobes on emulate_step and branch_taken

Haavard Skinnemoen (4):
      AVR32: Get rid of board_early_init
      AVR32: Fix thinko in generic_find_next_zero_le_bit()
      AVR32: Wire up sys_epoll_pwait
      AVR32: Add missing return instruction in __raw_writesb

Hartmut Hackmann (1):
      V4L/DVB (4770): Fix mode switch of Compro Videomate T300

Heiko Carstens (4):
      [NET]: fix uaccess handling
      sys_pselect7 vs compat_sys_pselect7 uaccess error handling
      [S390] revert add_active_range() usage patch.
      [S390] IRQs too early enabled.

Herbert Xu (2):
      [NET]: Fix segmentation of linear packets
      [SCTP]: Always linearise packet on input

Hugh Dickins (3):
      [POWERPC] Make current preempt-safe
      [POWERPC] Make high hugepage areas preempt safe
      [POWERPC] Make mmiowb's io_sync preempt safe

Jack Morgenstein (1):
      IB/uverbs: Return sq_draining value in query_qp response

James Morris (3):
      [IPV6]: fix lockup via /proc/net/ip6_flowlabel
      [IPV6]: return EINVAL for invalid address with flowlabel lease request
      [IPV6]: fix flowlabel seqfile handling

Jamie Lenehan (2):
      sh: Fix IPR-IRQ's for IRQ-chip change breakage.
      sh: Titan defconfig update.

Jan Luebbe (1):
      USB: sierra: Fix id for Sierra Wireless MC8755 in new table

Jan Mate (1):
      USB Storage: unusual_devs.h entry for Sony Ericsson P990i

Jan-Benedict Glaw (1):
      Update for the srm_env driver.

Jan-Bernd Themann (1):
      ehea: kzalloc GFP_ATOMIC fix

Jeff Dike (4):
      uml: add _text definition to linker scripts
      uml: add INITCALLS
      uml: fix I/O hang
      uml: include tidying

Jeff Garzik (1):
      Revert "Add 0x7110 piix to ata_piix.c"

Jeff Mahoney (1):
      reiserfs: reset errval after initializing bitmap cache

Jens Axboe (3):
      CFQ: request <-> request merging rr_list fixup
      Add 0x7110 piix to ata_piix.c
      splice: fix problem introduced with inode diet

Jes Sorensen (1):
      [IA64] don't double >> PAGE_SHIFT pointer for /dev/kmem access

Jiri Benc (1):
      ieee80211: don't flood log with errors

Johannes Berg (1):
      b44: change comment about irq mask register

Keith Owens (1):
      [IA64] Correct definition of handle_IPI

Kenji Kaneshige (1):
      [IA64] cpu-hotplug: Fixing confliction between CPU hot-add and IPI

Kevin Hilman (2):
      [ARM] 3917/1: Fix dmabounce symbol exports
      [ARM] 3918/1: ixp4xx irq-chip rework

Krishna Kumar (1):
      RDMA/cma: rdma_bind_addr() leaks a cma_dev reference count

Kristoffer Ericson (1):
      video: Fix include in hp680_bl.

Larry Finger (1):
      bcm43xx: fix unexpected LED control values in BCM4303 sprom

Larry Woodman (1):
      [NET]: __alloc_pages() failures reported due to fragmentation

Lennert Buytenhek (3):
      ep93xx_eth: fix RX/TXstatus ring full handling
      ep93xx_eth: fix unlikely(x) > y test
      ep93xx_eth: don't report RX errors

Linas Vepstas (1):
      [POWERPC] Use 4kB iommu pages even on 64kB-page systems

Linus Torvalds (6):
      i386: clean up io-apic accesses
      i386: write IO APIC irq routing entries in correct order
      Revert unintentional "volatile" changes in ipc/msg.c
      Fix unlikely (but possible) race condition on task->user access
      Make sure "user->sigpending" count is in sync
      Linux 2.6.19-rc5

Manish Lachwani (1):
      [MIPS] Add missing file for support of backplane on TX4927 based board

Martin Josefsson (1):
      [NETFILTER]: nf_conntrack: add missing unlock in get_next_corpse()

Meelis Roos (1):
      [NETFILTER]: silence a warning in ebtables

Michael Buesch (1):
      bcm43xx: Fix low-traffic netdev watchdog TX timeouts

Michael Chan (1):
      [TG3]: Fix 2nd ifup failure on 5752M.

Michael Halcrow (7):
      eCryptfs: Clean up crypto initialization
      eCryptfs: Hash code to new crypto API
      eCryptfs: Cipher code to new crypto API
      eCryptfs: Consolidate lower dentry_open's
      eCryptfs: Remove ecryptfs_umount_begin
      eCryptfs: Fix handling of lower d_count
      eCryptfs: Fix pointer deref

Michael S. Tsirkin (1):
      IB/mthca: Fix MAD extended header format for MAD_IFC firmware command

Naranjo Manuel Francisco (1):
      USB: HID: add blacklist AIRcable USB, little beautification

NeilBrown (2):
      md: check bio address after mapping through partitions.
      md: send online/offline uevents when an md array starts/stops

nkalmala (1):
      mm: un-needed add-store operation wastes a few bytes

OGAWA Hirofumi (4):
      Cleanup read_pages()
      cifs: ->readpages() fixes
      fuse: ->readpages() cleanup
      gfs2: ->readpages() fixes

Oleg Nesterov (2):
      taskstats: fix sub-threads accounting
      fix Documentation/accounting/getdelays.c buf size

Oliver Endriss (1):
      V4L/DVB (4784): [saa7146_i2c] short_delay mode fixed for fast machines

Oliver Neukum (2):
      USB: failure in usblp's error path
      USB: usblp: fix system suspend for some systems

Paolo 'Blaisorblade' Giarrusso (11):
      uml ubd driver: allow using up to 16 UBD devices
      uml ubd driver: document some struct fields
      uml ubd driver: var renames
      uml ubd driver: give better names to some functions.
      uml ubd driver: change ubd_lock to be a mutex
      uml ubd driver: ubd_io_lock usage fixup
      uml ubd driver: convert do_ubd to a boolean variable
      uml ubd driver: reformat ubd_config
      uml ubd driver: use bitfields where possible
      uml ubd driver: do not store error codes as ->fd
      uml ubd driver: various little changes

Patrick Caulfield (2):
      [DLM] Fix kref_put oops
      [DLM] fix oops in kref_put when removing a lockspace

Patrick McHardy (2):
      [NETFILTER]: remove masq/NAT from ip6tables Kconfig help
      [IPV6]: Give sit driver an appropriate module alias.

Paul Gortmaker (1):
      [ARM] 3912/1: Make PXA270 advertise HWCAP_IWMMXT capability

Paul Mackerras (2):
      IB/ehca: Fix eHCA driver compilation for uniprocessor
      powerpc: Eliminate "exceeds stub group size" linker warning

Paul Moore (2):
      [NetLabel]: protect the CIPSOv4 socket option from setsockopt()
      [NETLABEL]: Fix build failure.

Paul Mundt (2):
      sh: Wire up new syscalls.
      sh: Update r7780rp_defconfig.

Pavel Emelianov (1):
      Fix ipc entries removal

Pavel Roskin (1):
      hostap_plx: fix CIS verification

Peer Chen (5):
      [libata] sata_nv: Add PCI IDs
      [libata] Add support for PATA controllers of MCP67 to pata_amd.c.
      [libata] Add support for AHCI controllers of MCP67.
      pci_ids.h: Add NVIDIA PCI ID
      IDE: Add the support of nvidia PATA controllers of MCP67 to amd74xx.c

Peter Zijlstra (1):
      lockdep: fix delayacct locking bug

Phil Dibowitz (1):
      USB: usb-storage: Unusual_dev update

Rafael J. Wysocki (1):
      swsusp: debugging

Ralf Baechle (26):
      [MIPS] TX4927: Remove indent error message that somehow ended in the code.
      [MIPS] Sort out missuse of __init for prom_getcmdline()
      [MIPS] VSMP: Fix initialization ordering bug.
      [MIPS] Flags must be unsigned long.
      [MIPS] VSMP: Synchronize cp0 counters on bootup.
      [MIPS] 16K & 64K page size fixes
      [MIPS] SMTC: Fix crash if # of TC's > # of VPE's after pt_regs irq cleanup.
      [MIPS] SMTC: Synchronize cp0 counters on bootup.
      Revert "[MIPS] Make SPARSEMEM selectable on QEMU."
      [MIPS] Fix merge screwup by patch(1)
      [MIPS] IP27: Allow SMP ;-)  Another changeset messed up by patch.
      [MIPS] Fix warning about init_initrd() call if !CONFIG_BLK_DEV_INITRD.
      [MIPS] Ocelot G: Fix : "CURRENTLY_UNUSED" is not defined warning.
      [MIPS] Don't use R10000 llsc workaround version for all llsc-full processors.
      [MIPS] Ocelot C: Fix large number of warnings.
      [MIPS] Ocelot C: fix eth registration after conversion to platform_device
      [MIPS] Ocelot C: Fix warning about missmatching format string.
      [MIPS] Ocelot C: Fix mapping of ioport address range.
      [MIPS] Ocelot 3: Fix large number of warnings.
      [MIPS] SB1: On bootup only flush cache on local CPU.
      [MIPS] Ocelot C: Fix MAC address detection after platform_device conversion.
      [MIPS] Ocelot 3: Fix MAC address detection after platform_device conversion.
      [MIPS] EV64120: Fix timer initialization for HZ != 100.
      [MIPS] Make irq number allocator generally available for fixing EV64120.
      [MIPS] EV64120: Fix PCI interrupt allocation.
      [MIPS] Fix EV64120 and Ocelot builds by providing a plat_timer_setup().

Randy Dunlap (8):
      [NET] sealevel: uses arp_broken_ops
      [DCCP]: fix printk format warnings
      SCSI: ISCSI build failure
      V4L/DVB (4786): Pvrusb2: use NULL instead of 0
      update some docbook comments
      docbook: merge journal-api into filesystems.tmpl
      lkdtm: cleanup headers and module_param/MODULE_PARM_DESC
      Kconfig: remove redundant NETDEVICES depends

Ray Lehtiniemi (1):
      [ARM] 3927/1: Allow show_mem() to work with holes in memory map.

Raymond Mantchala (1):
      V4L/DVB (4787): Budget-ci: Inversion setting fixed for Technotrend 1500 T

Russ Anderson (1):
      [IA64] MCA recovery: Montecito support

Sean Hefty (1):
      RDMA/addr: Use client registration to fix module unload race

Srinivasa Ds (1):
      NFS4: fix for recursive locking problem

Stephen Hemminger (4):
      sky2: not experimental
      skge, sky2, et all. gplv2 only
      sky2: netpoll on dual port cards
      [TCP]: Set default congestion control when no sysctl.

Stephen Rothwell (3):
      Create compat_sys_migrate_pages
      powerpc: wire up sys_migrate_pages
      Fix sys_move_pages when a NULL node list is passed

Steve French (3):
      [CIFS] Fix readdir breakage when blocksize set too small
      [CIFS] Allow null user connections
      [CIFS] report rename failure when target file is locked by Windows

Steve Wise (2):
      IB/amso1100: Use dma_alloc_coherent() instead of kmalloc/dma_map_single
      IB/amso1100: Fix incorrect pr_debug()

Steven Whitehouse (2):
      [GFS2] Fix incorrect fs sync behaviour.
      [GFS2] Fix OOM error handling

Tejun Heo (4):
      sata_sis: fix flags handling for the secondary port
      libata: unexport ata_dev_revalidate()
      ata_piix: allow 01b MAP for both ICH6M and ICH7M
      ahci: fix status register check in ahci_softreset

Thomas Klein (3):
      ehea: Nullpointer dereferencation fix
      ehea: Removed redundant define
      ehea: 64K page support fix

Tilman Schmidt (1):
      isdn/gigaset: convert warning message

Timur Tabi (1):
      [POWERPC] qe_lib: qe_issue_cmd writes wrong value to CECDR

Trent Piepho (2):
      V4L/DVB (4752): DVB: Add DVB_FE_CUSTOMISE support for MT2060
      V4L/DVB (4751): Fix DBV_FE_CUSTOMISE for card drivers compiled into kernel

Troy Heber (1):
      [IA64] move SAL_CACHE_FLUSH check later in boot

Vasily Averin (1):
      [NETFILTER]: ip_tables: compat error way cleanup

Vlad Yasevich (2):
      [SCTP]: Correctly set IP id for SCTP traffic
      [SCTP]: Remove temporary associations from backlog and hash.

Yoichi Yuasa (3):
      [MIPS] Yosemite: fix uninitialized variable in titan_i2c_xfer()
      [MIPS] Fix warning of printk format in mips_srs_init()
      [MIPS] Fix warning in mips-boards generic PCI

Yvan Seth (1):
      ipmi_si_intf.c sets bad class_mask with PCI_DEVICE_CLASS

Re: Re: Re: 2.6.19-rc5: known regressions :SMP kernel can not generate ISA irq

[Komuro]

Hi,

>> Intel ISA PCIC probe: 
>>   Intel i82365sl B step ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 2 sockets
>>     host opts [0]: none
>>     host opts [1]: none
>>     ISA irqs (scanned) = 3,4,5,7,9,11,15 status change on irq 15
>
>This definitely means that the IRQ subsystem works, at least here. That 
>"scanned" means that the PCMCIA driver actually tested those interrupts, 
>and they worked.
>
>At that point, at least.
>
>Of course, the "they worked" test is fairly simple, so it's by no means 
>foolproof, but in general, it does sound like it all really should be ok.
>
>
>But testing 2.6.19-rc5 is still worth it. The APIC fixes might fix it, or 
>some other changes might.
>
>		Linus

I tried the 2.6.19-rc5,  the problem still happens.

But,
I remove the disable_irq_nosync() , enable_irq()
from the linux/drivers/net/pcmcia/axnet_cs.c
the interrupt is generated properly.

So I think enable_irq does not enable the irq.

Thanks!

Best Regards
Komuro

Re: Re: Re: 2.6.19-rc5: known regressions :SMP kernel can not generate ISA irq

[Linus Torvalds]

On Fri, 10 Nov 2006, Komuro wrote:
> 
> I tried the 2.6.19-rc5,  the problem still happens.

Ok, that's good data, and especially:

> But,
> I remove the disable_irq_nosync() , enable_irq()
> from the linux/drivers/net/pcmcia/axnet_cs.c
> the interrupt is generated properly.

All RIGHT. That's a very good clue. The major difference between PCI and 
ISA irq's is that they have different trigger types (they also have 
different polarity, but that tends to be just a small detail). In 
particular, ISA IRQ's are edge-triggered, and PCI IRQ's are level- 
triggered.

Now, edge-triggered interrupts are a _lot_ harder to mask, because the 
Intel APIC is an unbelievable piece of sh*t, and has the edge-detect logic 
_before_ the mask logic, so if a edge happens _while_ the device is 
masked, you'll never ever see the edge ever again (unmasking will not 
cause a new edge, so you simply lost the interrupt).

So when you "mask" an edge-triggered IRQ, you can't really mask it at all, 
because if you did that, you'd lose it forever if the IRQ comes in while 
you masked it. Instead, we're supposed to leave it active, and set a flag, 
and IF the IRQ comes in, we just remember it, and mask it at that point 
instead, and then on unmasking, we have to replay it by sending a 
self-IPI.

Maybe that part got broken by some of the IRQ changes by Eric. 

Eric, can you please double-check this all? I suspect you disable 
edge-triggered interrupts when moving them, or something, and maybe you 
didn't realize that if you disable them on the IO-APIC level, they can be 
gone forever.

[ Note: this is true EVEN IF we are in the interrupt handler right then - 
  if we get another edge while in the interrupt handler, the interrupt 
  will normally be _delayed_ until we've ACK'ed it, but if we have 
  _masked_ it, it will simply be lost entirely. So a simple "mask" 
  operation is always incorrect for edge-triggered interrupts.

  One option might be to do a simple mask, and on unmask, turn the edge 
  trigger into a level trigger at the same time. Then, the first time you 
  get the interrupt, you turn it back into an edge trigger _before_ you 
  call the interrupt handlers. That might actually be simpler than doing 
  the "irq replay" dance with self-IPI, because we can't actually just 
  fake the IRQ handling - when enable_irq() is called, irq's are normally 
  disabled on the CPU, so we can't just call the irq handler at that 
  point: we really do need to "replay" the dang thing.

  Did I mention that the Intel APIC's are a piece of cr*p already? ]

> So I think enable_irq does not enable the irq.

It probably does enable it (that's the easy part), but see above: if any 
of the support structure for the APIC crapola is subtly broken, we'll have 
lost the IRQ anyway.

(Many other IRQ controllers get this right: the "old and broken" Intel 
i8259 interrupt controller was a much better IRQ controller than the APIC 
in this regard, because it simply had the edge-detect logic after the 
masking logic, so if you unmasked an active interrupt that had been 
masked, you would always see it as an edge, and the i8259 controller needs 
none of the subtle code at _all_. It just works.)

Anyway, if you _can_ bisect the exact point where this started happening, 
that would be good. But I would not be surprised in the least if this is 
all introduced by Eric Biedermans dynamic IRQ handling.

Eric?

			Linus

Re: 2.6.19-rc5: known regressions :SMP kernel can not generate ISA irq

[Eric W. Biederman]

Linus Torvalds <torvalds@osdl.org> writes:

> On Fri, 10 Nov 2006, Komuro wrote:
>> 
>> I tried the 2.6.19-rc5,  the problem still happens.
>
> Ok, that's good data, and especially:
>
>> But,
>> I remove the disable_irq_nosync() , enable_irq()
>> from the linux/drivers/net/pcmcia/axnet_cs.c
>> the interrupt is generated properly.
>
> All RIGHT. That's a very good clue. The major difference between PCI and 
> ISA irq's is that they have different trigger types (they also have 
> different polarity, but that tends to be just a small detail). In 
> particular, ISA IRQ's are edge-triggered, and PCI IRQ's are level- 
> triggered.
>
> Now, edge-triggered interrupts are a _lot_ harder to mask, because the 
> Intel APIC is an unbelievable piece of sh*t, and has the edge-detect logic 
> _before_ the mask logic, so if a edge happens _while_ the device is 
> masked, you'll never ever see the edge ever again (unmasking will not 
> cause a new edge, so you simply lost the interrupt).
>
> So when you "mask" an edge-triggered IRQ, you can't really mask it at all, 
> because if you did that, you'd lose it forever if the IRQ comes in while 
> you masked it. Instead, we're supposed to leave it active, and set a flag, 
> and IF the IRQ comes in, we just remember it, and mask it at that point 
> instead, and then on unmasking, we have to replay it by sending a 
> self-IPI.
>
> Maybe that part got broken by some of the IRQ changes by Eric. 

Hmm.  The other possibility is that this is a genirq migration issue.

Yep.  That looks like it.   In the genirq migration the edge and
level triggered cases got merged and previously disable_edge_ioapic
was a noop.  Ouch.

Darn I missed this one in my review of Ingos changes.

I'm not at all certain what the correct fix here is.
- Do we make the make the generic code aware of this messed up
  case?  I believe it is aware of part of the don't disable edge
  triggered interrupt logic already.
- Do we modify the disable logic so it doesn't actually disable the
  irq?
- Do we do as Linus suggests and make the enable logic pass through a
  level triggered state?
- Do we split the edge and level triggered cases apart on again on
  i386 and x86_64?

And how do we make it drop dead clear what we are doing so that
someone doesn't break this in the future by accident.  That I
suspect was the real problem.  That stupid vector == irq case had
introduced so many levels of abstraction it was nearly impossible
to read the code.

Can we get this abstraction right so that we can make obviously
correct code here and still handle all of the weird code bugs?

> Eric, can you please double-check this all? I suspect you disable 
> edge-triggered interrupts when moving them, or something, and maybe you 
> didn't realize that if you disable them on the IO-APIC level, they can be 
> gone forever.

Sure.  So the hypothesis is that it is somewhere near commit
e7b946e98a456077dd6897f726f3d6197bd7e3b9 causing the problem. 

Anything I have changed in this area should affect both i386 and 
x86_64.

> [ Note: this is true EVEN IF we are in the interrupt handler right then - 
>   if we get another edge while in the interrupt handler, the interrupt 
>   will normally be _delayed_ until we've ACK'ed it, but if we have 
>   _masked_ it, it will simply be lost entirely. So a simple "mask" 
>   operation is always incorrect for edge-triggered interrupts.
>
>   One option might be to do a simple mask, and on unmask, turn the edge 
>   trigger into a level trigger at the same time. Then, the first time you 
>   get the interrupt, you turn it back into an edge trigger _before_ you 
>   call the interrupt handlers. That might actually be simpler than doing 
>   the "irq replay" dance with self-IPI, because we can't actually just 
>   fake the IRQ handling - when enable_irq() is called, irq's are normally 
>   disabled on the CPU, so we can't just call the irq handler at that 
>   point: we really do need to "replay" the dang thing.
>
>   Did I mention that the Intel APIC's are a piece of cr*p already? ]

Ok. After a quick skim it appears that there is a disable/enable pair
in the irq migration path for edge triggered interrupts.  But we
do that work while the irq is pending and it doesn't look like I
changed that part of the code.  Just the level triggered irq
migration.

>> So I think enable_irq does not enable the irq.
>
> It probably does enable it (that's the easy part), but see above: if any 
> of the support structure for the APIC crapola is subtly broken, we'll have 
> lost the IRQ anyway.
>
> (Many other IRQ controllers get this right: the "old and broken" Intel 
> i8259 interrupt controller was a much better IRQ controller than the APIC 
> in this regard, because it simply had the edge-detect logic after the 
> masking logic, so if you unmasked an active interrupt that had been 
> masked, you would always see it as an edge, and the i8259 controller needs 
> none of the subtle code at _all_. It just works.)
>
> Anyway, if you _can_ bisect the exact point where this started happening, 
> that would be good. But I would not be surprised in the least if this is 
> all introduced by Eric Biedermans dynamic IRQ handling.

I will share the credit because I missed this in code review but this
is really Ingo's generic irq code. 

Eric

Re: 2.6.19-rc5: known regressions :SMP kernel can not generate ISA irq

[Ingo Molnar]

On Mon, 2006-11-13 at 10:11 -0700, Eric W. Biederman wrote:
> > So when you "mask" an edge-triggered IRQ, you can't really mask it
> at all, 
> > because if you did that, you'd lose it forever if the IRQ comes in
> while 
> > you masked it. Instead, we're supposed to leave it active, and set a
> flag, 
> > and IF the IRQ comes in, we just remember it, and mask it at that
> point 
> > instead, and then on unmasking, we have to replay it by sending a 
> > self-IPI.
> >
> > Maybe that part got broken by some of the IRQ changes by Eric. 
> 
> Hmm.  The other possibility is that this is a genirq migration issue.
> 
> Yep.  That looks like it.   In the genirq migration the edge and
> level triggered cases got merged and previously disable_edge_ioapic
> was a noop.  Ouch.

hm, that should be solved by the generic edge-triggered flow handler as
well: we never mask an IRQ first time around, we only mask it if
we /already/ have the 'soft' IRQ_PENDING flag set. (in that case the
lost edge is not an issue because we have the information already - and
the masking will prevent a screaming edge source)

but maybe this concept has not been pushed through to the disable/enable
irq logic itself? (it's only present in the flow handler) Thomas, do you
concur?

	Ingo

Re: 2.6.19-rc5: known regressions :SMP kernel can not generate ISA irq

[Eric W. Biederman]

Ingo Molnar <mingo@redhat.com> writes:

> On Mon, 2006-11-13 at 10:11 -0700, Eric W. Biederman wrote:
>> > So when you "mask" an edge-triggered IRQ, you can't really mask it
>> at all, 
>> > because if you did that, you'd lose it forever if the IRQ comes in
>> while 
>> > you masked it. Instead, we're supposed to leave it active, and set a
>> flag, 
>> > and IF the IRQ comes in, we just remember it, and mask it at that
>> point 
>> > instead, and then on unmasking, we have to replay it by sending a 
>> > self-IPI.
>> >
>> > Maybe that part got broken by some of the IRQ changes by Eric. 
>> 
>> Hmm.  The other possibility is that this is a genirq migration issue.
>> 
>> Yep.  That looks like it.   In the genirq migration the edge and
>> level triggered cases got merged and previously disable_edge_ioapic
>> was a noop.  Ouch.
>
> hm, that should be solved by the generic edge-triggered flow handler as
> well: we never mask an IRQ first time around, we only mask it if
> we /already/ have the 'soft' IRQ_PENDING flag set. (in that case the
> lost edge is not an issue because we have the information already - and
> the masking will prevent a screaming edge source)
>
> but maybe this concept has not been pushed through to the disable/enable
> irq logic itself? (it's only present in the flow handler) Thomas, do you
> concur?

I just looked. I think the logic is actually in there as well.
I keep forgetting disable != mask.

I looks like what is really missing is that we aren't setting
IRQ_DELAYED_DISABLE.

So I think what we really need to do is just set IRQ_DELAYED_DISABLE.
Does the patch below look right?


Eric


diff --git a/arch/x86_64/kernel/io_apic.c b/arch/x86_64/kernel/io_apic.c
index 41bfc49..14654e6 100644
--- a/arch/x86_64/kernel/io_apic.c
+++ b/arch/x86_64/kernel/io_apic.c
@@ -790,9 +790,11 @@ static void ioapic_register_intr(int irq
 			trigger == IOAPIC_LEVEL)
 		set_irq_chip_and_handler_name(irq, &ioapic_chip,
 					      handle_fasteoi_irq, "fasteoi");
-	else
+	else {
+		irq_desc[irq].status |= IRQ_DELAYED_DISABLE;
 		set_irq_chip_and_handler_name(irq, &ioapic_chip,
 					      handle_edge_irq, "edge");
+	}
 }
 
 static void __init setup_IO_APIC_irqs(void)

[patch] irq: do not mask interrupts by default

[Ingo Molnar]

On Mon, 2006-11-13 at 14:11 -0700, Eric W. Biederman wrote:
> -       else
> +       else {
> +               irq_desc[irq].status |= IRQ_DELAYED_DISABLE;
>                 set_irq_chip_and_handler_name(irq, &ioapic_chip,
>                                               handle_edge_irq,
> "edge");
> +       }
>  } 

yeah. Komuro, could you try my patch below - Eric's patch only updates
x86_64 while your failure was on the i386 kernel.

Note, i also took another approach to fix this problem, that should
cover both the case found by Komuro, and some other cases as well. The
theory is this:

1) disable_irq() is relatively rare (used in about 10% of drivers, but
there it's overwhelmingly used in some slowpath) so it's performance
uncritical.

2) missing an IRQ while the line is masked is often a lethal regression
to the user. An IRQ could be missed even if we think that the IRQ line
is 'level-triggered'.

so my patch changes the default irq-disable logic of /all/ controllers
to "delayed disable". (IRQ chips can still override this by providing a
different chip->disable method that just clones their ->mask method, if
it is absolutely sure that no IRQs can be lost while masked)

So this patch has the worst-case effect of getting at most one 'extra'
interrupt after the IRQ line has been 'disabled' - at which point the
line will be masked for real (by the flow handler). (I updated the
fasteoi and the simple irq flow handlers to mask the IRQ for real if an
IRQ triggers and the line was disabled.)

It's a bit late in the -rc cycle for a change like this, but i'm fairly
positive about it. I booted it on a couple of boxes and saw no badness.
(neither did i see any increase in IRQ rates)

	Ingo

NOTE: this also means that the old IRQ_DELAYED_DISABLE bit can probably
be scrapped - i'll do that later on in a separate mail, if this patch
works out fine.

------------>
Subject: irq: do not mask interrupts by default
From: Ingo Molnar <mingo@elte.hu>

never mask interrupts immediately upon request. Disabling
interrupts in high-performance codepaths is rare, and on
the other hand this change could recover lost edges (or
even other types of lost interrupts) by conservatively
only masking interrupts after they happen. (NOTE: with
this change the highlevel irq-disable code still soft-disables
this IRQ line - and if such an interrupt happens then the
IRQ flow handler keeps the IRQ masked.)

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 kernel/irq/chip.c |   13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

Index: linux/kernel/irq/chip.c
===================================================================
--- linux.orig/kernel/irq/chip.c
+++ linux/kernel/irq/chip.c
@@ -202,10 +202,6 @@ static void default_enable(unsigned int 
  */
 static void default_disable(unsigned int irq)
 {
-	struct irq_desc *desc = irq_desc + irq;
-
-	if (!(desc->status & IRQ_DELAYED_DISABLE))
-		desc->chip->mask(irq);
 }
 
 /*
@@ -272,8 +268,11 @@ handle_simple_irq(unsigned int irq, stru
 	kstat_cpu(cpu).irqs[irq]++;
 
 	action = desc->action;
-	if (unlikely(!action || (desc->status & IRQ_DISABLED)))
+	if (unlikely(!action || (desc->status & IRQ_DISABLED))) {
+		if (desc->chip->mask)
+			desc->chip->mask(irq);
 		goto out_unlock;
+	}
 
 	desc->status |= IRQ_INPROGRESS;
 	spin_unlock(&desc->lock);
@@ -366,11 +365,13 @@ handle_fasteoi_irq(unsigned int irq, str
 
 	/*
 	 * If its disabled or no action available
-	 * keep it masked and get out of here
+	 * then mask it and get out of here:
 	 */
 	action = desc->action;
 	if (unlikely(!action || (desc->status & IRQ_DISABLED))) {
 		desc->status |= IRQ_PENDING;
+		if (desc->chip->mask)
+			desc->chip->mask(irq);
 		goto out;
 	}
 

Re: [patch] irq: do not mask interrupts by default

[Linus Torvalds]

On Tue, 14 Nov 2006, Ingo Molnar wrote:
> 
> 1) disable_irq() is relatively rare (used in about 10% of drivers, but
> there it's overwhelmingly used in some slowpath) so it's performance
> uncritical.

Well, the thing is, the _replay_ if it does happen, is going to be really 
really slow compared to the masking. So at that point, it may well be a 
net performance downside if the masking is going to almost always have an 
interrupt happen while the thing is masked. I dunno.

There's another thing too:

For level-triggered interrupts, I _really_ don't think we should do this. 
The code inside the masked region is sometimes "setup code", which will do 
things that _will_ raise an interrupt, but may read the status register or 
whatever to then unraise it. So in that case, your patch will generate 
different behaviour, something that I really don't want to introduce at 
this point in the 2.6.19 series.

> 2) missing an IRQ while the line is masked is often a lethal regression 
> to the user. An IRQ could be missed even if we think that the IRQ line 
> is 'level-triggered'.

If it's level-triggered, it's going to be missed only if it's de-asserted 
by code inside the masked region, and that is what we have always done on 
purpose, so "missing" it is the right thing to do. It's what we have 
tested all level-triggered interrupts with for the last 15+ years, and 
it's been part of the semantics for masking.

So I absolutely do _not_ think your change is improved semantics. It's new 
semantics, and illogical. If the driver masked the irq line, did some 
testing that raises and clears it again ("let's check if this version of 
the chip raises the interrupt when we do XYZZY"), then the logical thing 
to do would be to not cause the interrupt to happen.

Of course, for edge-triggered APIC interrupts, we _have_ to replay the irq 
(since we don't have any way of even *knowing* whether we might get it 
again), but for level-triggered and for the old legacy i8259 controller 
that gets it right for edges anwyay, we should _not_ send the spurious 
interrupt that is no longer active.

And a lot of code has been tested with either just the i8259 (old machines 
without any APIC) or with PCI-only devices (which are always level- 
triggered), so the fact that edge-triggered things have always seen the 
potential for spurious interrupts is not a reasong to say "well, they have 
to handle it anyway". True PCI drivers generally do _not_ have to handle 
the crazy case, and generally have never seen it.

> so my patch changes the default irq-disable logic of /all/ controllers 
> to "delayed disable". (IRQ chips can still override this by providing a 
> different chip->disable method that just clones their ->mask method, if 
> it is absolutely sure that no IRQs can be lost while masked)

I really think we should do this just for APIC edge triggered interrupts, 
ie keep the old behaviour.

Also, I worry a bit about the patch:

> @@ -272,8 +268,11 @@ handle_simple_irq(unsigned int irq, stru
>  	kstat_cpu(cpu).irqs[irq]++;
>  
>  	action = desc->action;
> -	if (unlikely(!action || (desc->status & IRQ_DISABLED)))
> +	if (unlikely(!action || (desc->status & IRQ_DISABLED))) {
> +		if (desc->chip->mask)
> +			desc->chip->mask(irq);
>  		goto out_unlock;
> +	}

The simple-irq case too? That's not even going to replay the thing? So now 
you just mask (without replaying) simple irqs, but then the other irqs you 
mask and replay.. See above on why I don't think this is necessarily a bug 
(since masking is almost always the right thing _anyway_), but now it will 
*STILL* depend on some internal implementation decision on whether the 
replay happens at all. I'd much rather have the replay decision be based 
on hard physical data: we replay _only_ for edge-triggered interrupts, and 
_only_ for controllers that need it. 

In other words, I think we should just make APIC-edge have the "please 
delay masking and replay" bit, and nobody else.

Can you send that patch (for both x86 and x86-64), and we can ask Komuro 
to test it. That would be the "same behaviour as we've always had" thing, 
which I think is also the _right_ behaviour.

		Linus

Re: [patch] genirq: do not mask interrupts by default

[Linus Torvalds]

On Wed, 15 Nov 2006, Ingo Molnar wrote:
> 
> problem is, we dont know /for a fact/ that something is "APIC-edge". We 
> only know that the BIOS claims it that it's so.

This is incorrect. We will have _programmed_ the APIC with whatever the 
BIOS said in the MP tables, so if we think it's level triggered, it _is_ 
level triggered.

So I really think that all the arguments for i8259 not wanting replay 
weigh equally on level-triggered PCI irq's too.

Now, the one thing that makes me think your approach is the right one is 
that it's potentially going to be better performance - if people disable 
irq's and the normal case is that no irq will actually happen, then 
optimistically not doing anything at all (except marking the irq disabled, 
of course) is always good.

However, because it's a semantic change, I _really_ don't want to do it 
right now. We're maybe a week away from 2.6.19, and the "ISA irq's don't 
work" report is one of the things that is holding things up right now.

So that's why I'd much rather go with Eric's patch for now - because it 
keeps the semantics that we've always had.

			Linus

Re: [patch] genirq: do not mask interrupts by default

[Ingo Molnar]

* Linus Torvalds <torvalds@osdl.org> wrote:

> On Wed, 15 Nov 2006, Ingo Molnar wrote:
> > 
> > problem is, we dont know /for a fact/ that something is "APIC-edge". 
> > We only know that the BIOS claims it that it's so.
> 
> This is incorrect. We will have _programmed_ the APIC with whatever 
> the BIOS said in the MP tables, so if we think it's level triggered, 
> it _is_ level triggered.

yeah. I was thinking about the low 16 irqs (those are really the problem 
spots most of the time, not the normal IO-APIC irqs) - which are routed 
all across the southbridge and might end up being handled by a 
i8259A-lookalike entity. Right now we default to level-triggered IRQ 
flow handling:

                if (i < 16) {
                        /*
                         * 16 old-style INTA-cycle interrupts:
                         */
                        set_irq_chip_and_handler_name(i, &i8259A_chip,
                                                      handle_level_irq, "XT");

because that's the best we can do (it's also what our i8259 code did 
historically). But it would be one step safer to also do the 
lazy-disable. Just in case things might get lost while masked. Or is 
that an absolutely horrible hardware breakage that i shouldnt worry 
about?

> So I really think that all the arguments for i8259 not wanting replay 
> weigh equally on level-triggered PCI irq's too.
> 
> Now, the one thing that makes me think your approach is the right one 
> is that it's potentially going to be better performance - if people 
> disable irq's and the normal case is that no irq will actually happen, 
> then optimistically not doing anything at all (except marking the irq 
> disabled, of course) is always good.
> 
> However, because it's a semantic change, I _really_ don't want to do 
> it right now. We're maybe a week away from 2.6.19, and the "ISA irq's 
> don't work" report is one of the things that is holding things up 
> right now.
>
> So that's why I'd much rather go with Eric's patch for now - because 
> it keeps the semantics that we've always had.

ok, i'm fine with Eric's patch too, if it solves Komuro's problem:

  Acked-by: Ingo Molnar <mingo@elte.hu>

and we dont have to worry about the present ugliness of the 
delayed-disabled flag either, as it would just go away in 2.6.20.

	Ingo