Re: 2.6.5-rc2-mm4 (and 3) IRQ problem

From: Len Brown (len.brown_at_intel.com)
Date: 03/30/04

  • Next message: Srivatsa Vaddagiri: "Re: route cache DoS testing and softirqs"
    To: Fabio Coatti <cova@ferrara.linux.it>
    Date:	29 Mar 2004 23:15:21 -0500
    
    

    Fabio,
    no ACPI badness jumps out at me.
    libata, uhci_hcd, or eth0 is likely at fault -- I'm not
    going to venture which -- remove what you can and
    see what makes the problem go away.

    cheers,
    -Len

    On Mon, 2004-03-29 at 17:29, Fabio Coatti wrote:

    > irq 18: nobody cared!
    > Call Trace:
    > [<c010882b>] __report_bad_irq+0x2a/0x8b
    > [<c0108937>] note_interrupt+0x91/0xaf
    > [<c0108c4a>] do_IRQ+0x151/0x19a
    > [<c034b4c8>] common_interrupt+0x18/0x20
    > [<c0104c2e>] default_idle+0x0/0x2c
    > [<c0104c57>] default_idle+0x29/0x2c
    > [<c0104cbb>] cpu_idle+0x2e/0x3c
    > [<c0430a02>] start_kernel+0x196/0x1c5
    > [<c0430436>] unknown_bootoption+0x0/0x126
    >
    > handlers:
    > [<c02a7b0b>] (ata_interrupt+0x0/0x173)
    > [<c02d2f9c>] (usb_hcd_irq+0x0/0x67)
    > Disabling IRQ #18

    > > > [root@kefk root]# cat /proc/interrupts
    > > > CPU0 CPU1
    > > > 0: 1002506 0 IO-APIC-edge timer
    > > > 1: 4722 0 IO-APIC-edge i8042
    > > > 2: 0 0 XT-PIC cascade
    > > > 9: 0 0 IO-APIC-level acpi
    > > > 12: 8826 0 IO-APIC-edge i8042
    > > > 14: 11920 0 IO-APIC-edge ide0
    > > > 15: 23 0 IO-APIC-edge ide1
    > > > 16: 278123 0 IO-APIC-level uhci_hcd, uhci_hcd, nvidia
    > > > 17: 2337 0 IO-APIC-level Intel ICH5
    > > > 18: 56240 0 IO-APIC-level libata, uhci_hcd, eth0
    > > > 19: 55 0 IO-APIC-level uhci_hcd
    > > > 22: 279 0 IO-APIC-level aic7xxx
    > > > 23: 0 0 IO-APIC-level ehci_hcd
    > > > NMI: 0 0
    > > > LOC: 1002427 1002439
    > > > ERR: 0
    > > > MIS: 0

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Srivatsa Vaddagiri: "Re: route cache DoS testing and softirqs"

    Relevant Pages

    • Re: [RFC] Changing COW detection to be memory hotplug friendly
      ... Keeping the swap slot ... is valuable if read fault, but once the page is dirtied, wouldn't ... I cannot imagine a good enough range of swap performance tests. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: All filesystems hang under long periods of heavy load (read and write) on a filesystem
      ... > the filesystem on the partition being written to. ... It seems that this boils down to using PIO mode, after enabling DMA I am ... the fault might not be fixed, it might just be less obvious... ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Stop the linux kernel madness - SOLVED!
      ... > So simply removing this symlink and putting back a link to ... IF the fault here is SUSE's, then submit THEM a bug report and stop whining in lkml. ... could have between lkml readers. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: system-freeze: kprobe and do_gettimeofday
      ... "insmod kgettime.ko" from the console ... double fault, ... Then I removed all my modules I was able to load the module ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] [Request for inclusion] Filesystem in Userspace
      ... > We actually had code that tracked the dirty bit in ... > software (ie make it unwritable by default, and take the write fault), but ... notes on kernel development methodology skipped ...] ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)