* Spurious interrupts when SCI shared with e100 @ 2004-11-08 10:59 Udo A. Steinberg 2004-11-08 20:54 ` [patch] e100 and shared interrupts [was: Spurious interrupts when SCI shared with e100] peter swain 2004-11-09 5:42 ` Spurious interrupts when SCI shared with e100 Len Brown 0 siblings, 2 replies; 5+ messages in thread From: Udo A. Steinberg @ 2004-11-08 10:59 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Len Brown My laptop has IRQ9 configured as ACPI SCI. When IRQ9 is shared between ACPI and e100 an IRQ9 storm occurs when e100 is enabled, as can be seen in the dmesg output below. The kernel then disables IRQ9, thus preventing e100 from working properly. The problem does not occur, if I override the default PCI steering in the BIOS, e.g. by routing LNKA to IRQ11. Nonetheless it would be good if someone could figure out why sharing IRQ9 is problematic. Thanks, -Udo. Linux version 2.6.10-rc1 (root@laptop.delusion.de) (gcc version 3.4.2) #2 Sun Nov 7 12:17:47 PST 2004 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f800 (usable) BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000000fff0000 (usable) BIOS-e820: 000000000fff0000 - 000000000fffec00 (ACPI data) BIOS-e820: 000000000fffec00 - 0000000010000000 (ACPI NVS) BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved) 255MB LOWMEM available. On node 0 totalpages: 65520 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 61424 pages, LIFO batch:14 HighMem zone: 0 pages, LIFO batch:1 DMI 2.3 present. ACPI: RSDP (v000 PTLTD ) @ 0x000f71a0 ACPI: RSDT (v001 PTLTD RSDT 0x06041160 LTP 0x00000000) @ 0x0fff4e5e ACPI: FADT (v001 IBM TP-T20 0x06041160 0x00000000) @ 0x0fffeb65 ACPI: BOOT (v001 PTLTD $SBFTBL$ 0x06041160 LTP 0x00000001) @ 0x0fffebd9 ACPI: DSDT (v001 IBM TP-T20 0x06041160 MSFT 0x0100000c) @ 0x00000000 ACPI: PM-Timer IO Port: 0x1008 Built 1 zonelists Kernel command line: parport=auto resume=/dev/hda2 video=vesa:mtrr vga=0x317 Initializing CPU#0 PID hash table entries: 1024 (order: 10, 16384 bytes) Detected 746.857 MHz processor. Using pmtmr for high-res timesource Console: colour dummy device 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 254700k/262080k available (2909k kernel code, 6812k reserved, 949k data, 156k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 1478.65 BogoMIPS (lpj=739328) Security Framework v1.0.0 initialized Capability LSM initialized Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: 0383f9ff 00000000 00000000 00000000 CPU: After vendor identify, caps: 0383f9ff 00000000 00000000 00000000 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K CPU: After all inits, caps: 0383f9ff 00000000 00000000 00000040 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: Intel Pentium III (Coppermine) stepping 03 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. ACPI: IRQ9 SCI: Level Trigger. NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfd94f, last bus=7 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20040816 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 9 10 11) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11) ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT] ACPI: Power Resource [PSER] (on) ACPI: Power Resource [PSIO] (on) ACPI: Embedded Controller [EC] (gpe 9) Linux Kernel Card Services options: [pci] [cardbus] [pm] usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 5 ACPI: PCI interrupt 0000:00:02.1[B] -> GSI 5 (level, low) -> IRQ 5 ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 9 ACPI: PCI interrupt 0000:00:03.0[A] -> GSI 9 (level, low) -> IRQ 9 ACPI: PCI interrupt 0000:00:03.1[A] -> GSI 9 (level, low) -> IRQ 9 ACPI: PCI interrupt 0000:00:05.0[A] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10 ACPI: PCI interrupt 0000:00:07.2[D] -> GSI 10 (level, low) -> IRQ 10 ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11 Simple Boot Flag at 0x35 set to 0x1 Installing knfsd (copyright (C) 1996 okir@monad.swb.de). NTFS driver 2.1.21 [Flags: R/O]. Initializing Cryptographic API Limiting direct PCI/PCI transfers. vesafb: framebuffer at 0xf0000000, mapped to 0xd0880000, using 3072k, total 8192k vesafb: mode is 1024x768x16, linelength=2048, pages=4 vesafb: protected mode interface info at c000:87f7 vesafb: scrolling: redraw vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0 Console: switching to colour frame buffer device 128x48 fb0: VESA VGA frame buffer device ACPI: AC Adapter [AC] (on-line) ACPI: Battery Slot [BAT0] (battery present) ACPI: Battery Slot [BAT1] (battery present) ACPI: Power Button (FF) [PWRF] ACPI: Lid Switch [LID] ACPI: Sleep Button (CM) [SLPB] ACPI: Processor [CPU] (supports C1 C2 C3, 8 throttling states) ACPI: Thermal Zone [THM0] (59 C) Real Time Clock Driver v1.12 Non-volatile memory driver v1.2 Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected an Intel 440BX Chipset. agpgart: Maximum main memory to use for agp memory: 203M agpgart: AGP aperture is 64M @ 0xf8000000 serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ACPI: PCI interrupt 0000:00:03.1[A] -> GSI 9 (level, low) -> IRQ 9 parport0: PC-style at 0x3bc (0x7bc), irq 7, using FIFO [PCSPP,TRISTATE,COMPAT,ECP] io scheduler noop registered io scheduler deadline registered elevator: using deadline as default io scheduler Floppy drive(s): fd0 is 1.44M FDC 0 is a National Semiconductor PC87306 loop: loaded (max 8 devices) e100: Intel(R) PRO/100 Network Driver, 3.0.27-k2-NAPI e100: Copyright(c) 1999-2004 Intel Corporation ACPI: PCI interrupt 0000:00:03.0[A] -> GSI 9 (level, low) -> IRQ 9 irq 9: nobody cared! [<c0132544>] __report_bad_irq+0x24/0x80 [<c013265e>] note_interrupt+0x8e/0xb0 [<c0131ec4>] handle_IRQ_event+0x34/0x70 [<c013205b>] __do_IRQ+0x15b/0x180 [<c0105c06>] do_IRQ+0x26/0x40 [<c0104228>] common_interrupt+0x18/0x20 [<c011f30d>] __do_softirq+0x2d/0x90 [<c011f397>] do_softirq+0x27/0x30 [<c0131e85>] irq_exit+0x35/0x40 [<c0105c0b>] do_IRQ+0x2b/0x40 [<c0104228>] common_interrupt+0x18/0x20 [<c01480f6>] __get_vm_area+0x146/0x220 [<c0216ccd>] pci_bus_read_config_byte+0x6d/0x70 [<c01481f7>] get_vm_area+0x27/0x30 [<c0113a86>] __ioremap+0xc6/0x120 [<c028f6a1>] e100_probe+0x241/0x530 [<c0168814>] d_alloc+0x154/0x180 [<c0168f76>] d_rehash+0x66/0x70 [<c0169986>] alloc_inode+0xd6/0x180 [<c016889f>] d_instantiate+0x5f/0x80 [<c0183c3b>] sysfs_create+0x7b/0xe0 [<c021a5c6>] pci_device_probe_static+0x46/0x70 [<c021a629>] __pci_device_probe+0x39/0x50 [<c021a663>] pci_device_probe+0x23/0x50 [<c0277132>] bus_match+0x32/0x70 [<c027726d>] driver_attach+0x4d/0x90 [<c020c052>] kobject_register+0x22/0x60 [<c027775f>] bus_add_driver+0x8f/0xc0 [<c0277cc8>] driver_register+0x28/0x30 [<c011b087>] printk+0x17/0x20 [<c021a909>] pci_register_driver+0x59/0x80 [<c04c87b4>] do_initcalls+0x54/0xc0 [<c0100440>] init+0x0/0x140 [<c0100440>] init+0x0/0x140 [<c0100475>] init+0x35/0x140 [<c01022a8>] kernel_thread_helper+0x0/0x18 [<c01022ad>] kernel_thread_helper+0x5/0x18 handlers: [<c022a06f>] (acpi_irq+0x0/0x14) Disabling IRQ #9 e100: eth0: e100_probe: addr 0xe8120000, irq 9, MAC addr 00:02:B3:06:0A:A8 ^ permalink raw reply [flat|nested] 5+ messages in thread
* [patch] e100 and shared interrupts [was: Spurious interrupts when SCI shared with e100] 2004-11-08 10:59 Spurious interrupts when SCI shared with e100 Udo A. Steinberg @ 2004-11-08 20:54 ` peter swain 2004-11-09 22:22 ` J.A. Magallon 2004-11-09 5:42 ` Spurious interrupts when SCI shared with e100 Len Brown 1 sibling, 1 reply; 5+ messages in thread From: peter swain @ 2004-11-08 20:54 UTC (permalink / raw) To: Udo A. Steinberg Cc: Linux Kernel Mailing List, Len Brown, andrews, scott.feldman [-- Attachment #1: Type: text/plain, Size: 3463 bytes --] Udo A. Steinberg wrote: >My laptop has IRQ9 configured as ACPI SCI. When IRQ9 is shared between ACPI >and e100 an IRQ9 storm occurs when e100 is enabled, as can be seen in the >dmesg output below. The kernel then disables IRQ9, thus preventing e100 from >working properly. The problem does not occur, if I override the default PCI >steering in the BIOS, e.g. by routing LNKA to IRQ11. > >Nonetheless it would be good if someone could figure out why sharing IRQ9 >is problematic. > > Udo, please try the attached 2.6.9 patch. I suspect intel e100 driver always had problems with shared interrupts, due to a classic case of "executable comment syndrome" in the original intel driver. I noticed races on some of our ancient boxes with e100s, sharing interrupts with other e100s, or other cards. The intel e100 v2.0.40 e100intr() code says..... intr_status = readw(&bdp->scb->scb_status); /* If not my interrupt, just return */ if (!(intr_status & SCB_STATUS_ACK_MASK) || (intr_status == 0xffff)) { return IRQ_NONE; } But the test above is *not* "not my interrupt" but "no interesting conditions". Both tests are needed for reliable operation in a shared-irq scenario. When the driver is meddling with e100 setup, causing intr_status bits to pop up, but has not yet enabled e100 interrupts, a "stray" interrupt from a device sharing the IRQ will cause e100intr() to walk all over the device even if the driver is in a critical section. Chaos ensues -- in my case duplicate skb_free calls when a parasitic interrupt "completed" processing of tx ring skbs which napi bh was still setting up. Compare with becker's eepro100, where there are (IIRC) 3 locks -- a lock on tx resources, a lock on rx resources, and an implicit lock by way of the card's interrupt-enable bit. If you enable interrupts, you're allowing the irq-handler to play with tx,rx resources without any other locks. So a courteous irq-handler will check to see if it has been granted the privilege, by inspecting the interrupt-enable bit. Other drivers follow this model, but e100 driver merely has a misleading comment instead of the check. I'd guess that Udo's problem appears when... - e100 driver is meddling with card, with e100 interrupt enable *off* - ACPI interrupt causes e100intr to be invoked parasitcally, cleaning up (or breaking) some half-finished work intended to be guarded by interrupt-enable bit - driver enables e100 interrupt - e100-driven IRQ calls e100intr(), finds no work to do - (conjecture) 2.6.10-rc1 actually checks the IRQ_NONE return, notes spurious interrupt & disables IRQ Our e100 problems went away on hundreds of old linux-2.4 dual-e100 boxes when the attached e100-v2-irq-share.patch was applied. It applies cleanly to linux-2.4.27, but is untested there. I'd seen no lkml mention of shared-irq e100 problems, so was letting it bake for a couple of weeks before declaring success, porting it to recent 2.6 and publishing. But Udo has a problem, so let's see if this fixes it... My linux-2.6.9 patch is an untested transliteration to intel's e100-v3 driver structure. (v3 driver has one e100.c, v2 has e100/*.c tree, cutover was about 2.6.4? 5?) I'm not sure if this is implicated in the widespread mistrust of e100 multiport cards under linux, the e100-eepro100 wars, or the recent e100-suspend problems. Could be the missing piece in all. ^..^ feedback very welcome (oo) [-- Attachment #2: e100-v2-irq-share.patch --] [-- Type: text/plain, Size: 1709 bytes --] ## add a module param own_irq=1 to forbid interrupt sharing ## add a check in e100intr for device interrupt masking -- if the driver has masked irqs off, ## don't execute the usual irq service, but simply report the clash --- Linux/drivers/net/e100/e100_main.c Thu Oct 21 17:25:24 2004 +++ linux/drivers/net/e100/e100_main.c Fri Oct 22 11:45:27 2004 @@ -424,6 +424,9 @@ E100_PARAM(BundleMax, "Maximum number fo E100_PARAM(IFS, "Disable or enable the adaptive IFS algorithm"); E100_PARAM(weight, "rx packets processed per poll"); +int own_irq = 0; /* every card gets *own* IRQ? */ +MODULE_PARM(own_irq, "i"); + /** * e100_exec_cmd - issue a comand * @bdp: atapter's private data struct @@ -1153,7 +1156,7 @@ e100_open(struct net_device *dev) netif_start_queue(dev); e100_start_ru(bdp); - if ((rc = request_irq(dev->irq, &e100intr, SA_SHIRQ, + if ((rc = request_irq(dev->irq, &e100intr, own_irq ? 0 : SA_SHIRQ, dev->name, dev)) != 0) { del_timer_sync(&bdp->watchdog_timer); goto err_exit; @@ -2062,11 +2065,20 @@ e100intr(int irq, void *dev_inst, struct dev = dev_inst; bdp = dev->priv; - intr_status = readw(&bdp->scb->scb_status); /* If not my interrupt, just return */ - if (!(intr_status & SCB_STATUS_ACK_MASK) || (intr_status == 0xffff)) { + if (readb(&bdp->scb->scb_cmd_hi) & SCB_INT_MASK) { + static int once = 0; + + if (!once) + printk(KERN_ERR "e100intr ignoring disabled interrupt, suspect irq-sharing\n"); + once = 1; return IRQ_NONE; } + + /* If no pending action, just return */ + intr_status = readw(&bdp->scb->scb_status); + if (!(intr_status & SCB_STATUS_ACK_MASK) || (intr_status == 0xffff)) + return IRQ_NONE; #ifdef CONFIG_E100_NAPI [-- Attachment #3: e100-linux-2.6.9-irq-sharing.patch --] [-- Type: text/plain, Size: 807 bytes --] --- drivers/net/e100.c-pre-swine Mon Nov 8 12:19:08 2004 +++ drivers/net/e100.c Mon Nov 8 12:25:36 2004 @@ -1580,11 +1580,18 @@ static irqreturn_t e100_intr(int irq, vo { struct net_device *netdev = dev_id; struct nic *nic = netdev_priv(netdev); - u8 stat_ack = readb(&nic->csr->scb.stat_ack); + u8 stat_ack, cmd_hi; + cmd_hi = readb(&nic->csr->scb.cmd_hi); + DPRINTK(INTR, DEBUG, "cmd_hi = 0x%02X\n", cmd_hi); + + if(cmd_hi & irq_mask_all) /* Not our interrupt */ + return IRQ_NONE; + + stat_ack = readb(&nic->csr->scb.stat_ack); DPRINTK(INTR, DEBUG, "stat_ack = 0x%02X\n", stat_ack); - if(stat_ack == stat_ack_not_ours || /* Not our interrupt */ + if(stat_ack == stat_ack_not_ours || /* nothing to do */ stat_ack == stat_ack_not_present) /* Hardware is ejected */ return IRQ_NONE; ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [patch] e100 and shared interrupts [was: Spurious interrupts when SCI shared with e100] 2004-11-08 20:54 ` [patch] e100 and shared interrupts [was: Spurious interrupts when SCI shared with e100] peter swain @ 2004-11-09 22:22 ` J.A. Magallon 0 siblings, 0 replies; 5+ messages in thread From: J.A. Magallon @ 2004-11-09 22:22 UTC (permalink / raw) To: linux-kernel On 2004.11.08, peter swain wrote: > Udo A. Steinberg wrote: > > >My laptop has IRQ9 configured as ACPI SCI. When IRQ9 is shared between ACPI > >and e100 an IRQ9 storm occurs when e100 is enabled, as can be seen in the > >dmesg output below. The kernel then disables IRQ9, thus preventing e100 from > >working properly. The problem does not occur, if I override the default PCI > >steering in the BIOS, e.g. by routing LNKA to IRQ11. > > > >Nonetheless it would be good if someone could figure out why sharing IRQ9 > >is problematic. > > > > > Udo, please try the attached 2.6.9 patch. > With this patch, I still get things like this: Nov 9 22:24:14 nada kernel: e100: Intel(R) PRO/100 Network Driver, 3.2.3-k2-NAPI Nov 9 22:24:14 nada kernel: e100: Copyright(c) 1999-2004 Intel Corporation Nov 9 22:24:14 nada kernel: ACPI: PCI interrupt 0000:00:0d.0[A] -> GSI 19 (level, low) -> IRQ 185 Nov 9 22:24:14 nada kernel: e100: eth0: e100_probe: addr 0xf7161000, irq 185, MAC addr 00:30:48:41:22:9F Nov 9 22:24:14 nada kernel: Badness in enable_irq at kernel/irq/manage.c:106 Nov 9 22:24:14 nada kernel: [enable_irq+178/256] enable_irq+0xb2/0x100 Nov 9 22:24:14 nada kernel: [<b0136aa2>] enable_irq+0xb2/0x100 Nov 9 22:24:14 nada kernel: [pg0+1078951656/1337152512] e100_up+0xe8/0x1f0 [e100] Nov 9 22:24:14 nada kernel: [<f09c0ee8>] e100_up+0xe8/0x1f0 [e100] Nov 9 22:24:14 nada kernel: [pg0+1078955962/1337152512] e100_open+0x2a/0x90 [e100] Nov 9 22:24:14 nada kernel: [<f09c1fba>] e100_open+0x2a/0x90 [e100] Nov 9 22:24:14 nada kernel: [dev_open+116/144] dev_open+0x74/0x90 Nov 9 22:24:14 nada kernel: [<b02f1b74>] dev_open+0x74/0x90 Nov 9 22:24:14 nada kernel: [dev_change_flags+86/304] dev_change_flags+0x56/0x130 Nov 9 22:24:14 nada kernel: [<b02f3056>] dev_change_flags+0x56/0x130 Nov 9 22:24:14 nada kernel: [devinet_ioctl+1522/1696] devinet_ioctl+0x5f2/0x6a0 Nov 9 22:24:14 nada kernel: [<b032cd72>] devinet_ioctl+0x5f2/0x6a0 Nov 9 22:24:14 nada kernel: [inet_ioctl+223/256] inet_ioctl+0xdf/0x100 Nov 9 22:24:14 nada kernel: [<b032ec7f>] inet_ioctl+0xdf/0x100 Nov 9 22:24:14 nada kernel: [sock_ioctl+435/624] sock_ioctl+0x1b3/0x270 Nov 9 22:24:14 nada kernel: [<b02e9163>] sock_ioctl+0x1b3/0x270 Nov 9 22:24:14 nada kernel: [fget+73/96] fget+0x49/0x60 Nov 9 22:24:14 nada kernel: [<b0156f59>] fget+0x49/0x60 Nov 9 22:24:14 nada kernel: [sys_ioctl+517/624] sys_ioctl+0x205/0x270 Nov 9 22:24:14 nada kernel: [<b0168185>] sys_ioctl+0x205/0x270 Nov 9 22:24:14 nada kernel: [sysenter_past_esp+82/113] sysenter_past_esp+0x52/0x71 Nov 9 22:24:14 nada kernel: [<b0105add>] sysenter_past_esp+0x52/0x71 Nov 9 22:24:14 nada kernel: e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex -- J.A. Magallon <jamagallon()able!es> \ Software is like sex: werewolf!able!es \ It's better when it's free Mandrakelinux release 10.2 (Cooker) for i586 Linux 2.6.9-jam1 (gcc 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)) #10 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Spurious interrupts when SCI shared with e100 2004-11-08 10:59 Spurious interrupts when SCI shared with e100 Udo A. Steinberg 2004-11-08 20:54 ` [patch] e100 and shared interrupts [was: Spurious interrupts when SCI shared with e100] peter swain @ 2004-11-09 5:42 ` Len Brown 2004-11-09 16:21 ` Phil Oester 1 sibling, 1 reply; 5+ messages in thread From: Len Brown @ 2004-11-09 5:42 UTC (permalink / raw) To: Udo A. Steinberg Cc: Linux Kernel Mailing List, ganesh.venkatesan, John Ronciak On Mon, 2004-11-08 at 05:59, Udo A. Steinberg wrote: > My laptop has IRQ9 configured as ACPI SCI. When IRQ9 is shared between > ACPI and e100 an IRQ9 storm occurs when e100 is enabled, as can be > seen in the dmesg output below. Is this new with 2.6.10-rc1, or has it always been broken in an ACPI-enabled kernel with acpi sharing an irq with e100? I suspect this may be a bug in the e100 -- it may have enabled interrupts before it has registered a handler. Assuming it is a receive interrupt, you may be able to verify this by plugging in the network cable after the system has probed e100 and see if it works normally after that. Also, you might try out the eepro100 driver to see if it behaves any differently. thanks, -Len ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Spurious interrupts when SCI shared with e100 2004-11-09 5:42 ` Spurious interrupts when SCI shared with e100 Len Brown @ 2004-11-09 16:21 ` Phil Oester 0 siblings, 0 replies; 5+ messages in thread From: Phil Oester @ 2004-11-09 16:21 UTC (permalink / raw) To: Len Brown Cc: Udo A. Steinberg, Linux Kernel Mailing List, ganesh.venkatesan, John Ronciak On Tue, Nov 09, 2004 at 12:42:46AM -0500, Len Brown wrote: > On Mon, 2004-11-08 at 05:59, Udo A. Steinberg wrote: > > My laptop has IRQ9 configured as ACPI SCI. When IRQ9 is shared between > > ACPI and e100 an IRQ9 storm occurs when e100 is enabled, as can be > > seen in the dmesg output below. > > Is this new with 2.6.10-rc1, or has it always been broken in an > ACPI-enabled kernel with acpi sharing an irq with e100? > > I suspect this may be a bug in the e100 -- it may have enabled > interrupts before it has registered a handler. I saw similar behaviour in 2.6.8.1 on a non-ACPI enabled kernel with a dual-port e100. The nic simply would not work, spewing this error in syslog: NETDEV WATCHDOG: eth1: transmit timed out If I booted with an ACPI enabled kernel, the box worked again. IRQ sharing was involved, though can't recall which IRQ eth1 tried to use. This was on a brand new Dell Optiplex. Phil ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-11-09 22:23 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-11-08 10:59 Spurious interrupts when SCI shared with e100 Udo A. Steinberg 2004-11-08 20:54 ` [patch] e100 and shared interrupts [was: Spurious interrupts when SCI shared with e100] peter swain 2004-11-09 22:22 ` J.A. Magallon 2004-11-09 5:42 ` Spurious interrupts when SCI shared with e100 Len Brown 2004-11-09 16:21 ` Phil Oester
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.