From: Roger Heflin <rheflin@atipa.com>
To: Linux-Kernel <linux-kernel@vger.kernel.org>, linux-ide@vger.kernel.org
Subject: What determines which interrupts are shared under Linux?
Date: Tue, 15 Aug 2006 09:17:04 -0500 [thread overview]
Message-ID: <44E1D760.6070600@atipa.com> (raw)
Hello,
On Linux when interrupts are defined similar to below, what defines say
ide2, ide3 to be on the same interrupt? The bios, linux, the driver using
the interrupt? And can that be controlled/overrode at the
kernel/driver level?
I have identified that the disks that are shared on ide2, ide3 do funny
things when both are being heavily used (dma_expiry), this is an older
driver versions
but I have experienced it before with a lot newer driver, and a bios
adjustment
previously fixed a similar issue, so that may be what is needed in this
case also,
I am not sure how they fixed it, but I suspect that the setup the interrupt
to not be shared. I have a large number of machines and under heavy
loads all
seem to duplicate the issue, and it always happens with the disks on
ide2/ide3,
never on the disk connected to ide4.
CPU0 CPU1 CPU2 CPU3
0: 56616921 5359998 7002142 938817 XT-PIC timer
1: 8 88 96 0 IO-APIC-edge i8042
2: 0 0 0 0 XT-PIC cascade
4: 2091 100 208 2477 IO-APIC-edge serial
8: 0 0 0 0 IO-APIC-edge rtc
9: 0 0 0 0 IO-APIC-level acpi
20: 0 0 0 0 IO-APIC-level ehci_hcd
21: 0 950 401419 414482 IO-APIC-level ide4,
ohci_hcd
22: 1165 1704243 576247 6796 IO-APIC-level ide2,
ide3
47: 65971 0 0 0 IO-APIC-level eth0
NMI: 1 1 1 1
LOC: 69904264 69877733 69879541 69901903
ERR: 0
MIS: 105
Roger
next reply other threads:[~2006-08-15 14:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-15 14:17 Roger Heflin [this message]
2006-08-15 14:30 ` What determines which interrupts are shared under Linux? Sergei Shtylyov
2006-08-15 14:38 ` Roger Heflin
2006-08-15 14:47 ` Len Brown
2006-08-15 15:06 ` Alan Cox
2006-08-15 15:24 ` Roger Heflin
2006-08-15 15:55 ` Alan Cox
2006-08-15 17:47 ` Roger Heflin
2006-08-15 18:13 ` Alan Cox
2006-08-16 22:54 ` Mark Lord
2006-08-17 0:39 ` Alan Cox
2006-08-17 13:18 ` Roger Heflin
2006-08-15 15:19 ` linux-os (Dick Johnson)
2006-08-15 17:31 ` Terence Ripperda
2006-08-15 17:42 ` Sergei Shtylyov
2006-08-15 17:43 ` Terence Ripperda
[not found] <fa.xiop2gho7OdOydmzXzpUsR5ksXM@ifi.uio.no>
2006-08-15 14:29 ` Robert Hancock
[not found] ` <fa.1abHK6YDIfV51f77xhbkgnQpLwk@ifi.uio.no>
[not found] ` <fa.UkMpPU+vkXMkIeBVGEpBG9C87M4@ifi.uio.no>
[not found] ` <fa.9EHh5X478LQIXFY79H/n57rBfRE@ifi.uio.no>
[not found] ` <fa.OQ0aZlfKc9NmI+ugRx8PT515Nks@ifi.uio.no>
2006-08-15 23:04 ` Robert Hancock
2006-08-15 23:11 ` Roger Heflin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44E1D760.6070600@atipa.com \
--to=rheflin@atipa.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox