From: Russell King
[ Upstream commit 30e3b4f256b4e366a61658c294f6a21b8626dda7 ]
Since commit 30fdfb929e82 ("PCI: Add a call to pci_assign_irq() in
pci_device_probe()"), the PCI code will call the IRQ mapping function
whenever a PCI driver is probed. If these are marked as __init, this
causes an
From: Russell King
[ Upstream commit 30e3b4f256b4e366a61658c294f6a21b8626dda7 ]
Since commit 30fdfb929e82 ("PCI: Add a call to pci_assign_irq() in
pci_device_probe()"), the PCI code will call the IRQ mapping function
whenever a PCI driver is probed. If these are marked as __init, this
causes an
From: Russell King
[ Upstream commit 30e3b4f256b4e366a61658c294f6a21b8626dda7 ]
Since commit 30fdfb929e82 ("PCI: Add a call to pci_assign_irq() in
pci_device_probe()"), the PCI code will call the IRQ mapping function
whenever a PCI driver is probed. If these are marked as __init, this
causes an
gt; > >
> > > On Wed, Jan 06, 2021 at 02:55:40PM +0100, Martin Blumenstingl wrote:
> > > > The legacy PCI interrupt lines need to be enabled using PCIE_APP_IRNEN
> > > > bits 13 (INTA), 14 (INTB), 15 (INTC) and 16 (INTD). The old code
> &g
On 9/4/2021 4:40 am, Martin Blumenstingl wrote:
> This email was sent from outside of MaxLinear.
>
> Hi Lorenzo,
>
> On Tue, Mar 23, 2021 at 12:36 PM Lorenzo Pieralisi
> wrote:
> >
> > On Wed, Jan 06, 2021 at 02:55:40PM +0100, Martin Blumenstingl wrote:
> &
Hi Lorenzo,
On Tue, Mar 23, 2021 at 12:36 PM Lorenzo Pieralisi
wrote:
>
> On Wed, Jan 06, 2021 at 02:55:40PM +0100, Martin Blumenstingl wrote:
> > The legacy PCI interrupt lines need to be enabled using PCIE_APP_IRNEN
> > bits 13 (INTA), 14 (INTB), 15 (INTC) and 16 (INTD). Th
On Wed, Jan 06, 2021 at 02:55:40PM +0100, Martin Blumenstingl wrote:
> The legacy PCI interrupt lines need to be enabled using PCIE_APP_IRNEN
> bits 13 (INTA), 14 (INTB), 15 (INTC) and 16 (INTD). The old code however
> was taking (for example) "13" as raw value instead of takin
The legacy PCI interrupt lines need to be enabled using PCIE_APP_IRNEN
bits 13 (INTA), 14 (INTB), 15 (INTC) and 16 (INTD). The old code however
was taking (for example) "13" as raw value instead of taking BIT(13).
Define the legacy PCI interrupt bits using the BIT() macro and then us
The ResourceSource field of an Extended Interrupt Descriptor was ignored
when the driver is parsing _PRS method of PNP0C0F PCI Interrupt Link
devices, which means PCI INTx would be always registered under the GSI
domain. This patch introduces stacked IRQ domain support to PCI Interrupt
Link
The ResourceSource field of an Extended Interrupt Descriptor was ignored
when the driver is parsing _PRS method of PNP0C0F PCI Interrupt Link
devices, which means PCI INTx would be always registered under the GSI
domain. This patch introduces stacked IRQ domain support to PCI Interrupt
Link
On Wed, Nov 18, 2020 at 10:05:29PM +0800, Chen Baozi wrote:
> Hi Lorenzo,
>
> > On Nov 18, 2020, at 5:51 PM, Lorenzo Pieralisi
> > wrote:
> >
> > On Tue, Nov 17, 2020 at 09:42:14PM +0800, Chen Baozi wrote:
> >> Some PCIe designs require software to do extra acknowledgements for
> >> legacy INTx
Hi Lorenzo,
> On Nov 18, 2020, at 5:51 PM, Lorenzo Pieralisi
> wrote:
>
> On Tue, Nov 17, 2020 at 09:42:14PM +0800, Chen Baozi wrote:
>> Some PCIe designs require software to do extra acknowledgements for
>> legacy INTx interrupts. If the driver is written only for device tree,
>> things are si
gt; Similar designs can be found on Aardvark, MediaTek Gen2 and Socionext
> > > UniPhier PCIe controller at the moment. Essentially, those designs are
> > > supported by inserting an extra interrupt controller between PCIe host
> > > and GIC and parse the topology in a DT-
controller between PCIe host
> > and GIC and parse the topology in a DT-based PCI controller driver.
>
> If I understand correctly, we previously ignored the Resource Source
> field of an Extended Interrupt Descriptor in the _PRS method of
> PNP0C0F PCI Interrupt Link devices, a
Hi Marc,
> On Nov 18, 2020, at 5:27 PM, Marc Zyngier wrote:
>
> Hi Chen,
>
> On top of Bjorn's comments:
>
> On 2020-11-17 13:42, Chen Baozi wrote:
>>
>> ---
>> drivers/acpi/irq.c | 22 +-
>> drivers/acpi/pci_irq.c | 6 --
>> drivers/acpi/pci_link.c |
directory and try to follow
> the existing convention. Using random styles adds noise to the
> system.
>
> On Tue, Nov 17, 2020 at 09:42:14PM +0800, Chen Baozi wrote:
>>
>> Therefore, we introduce an stacked IRQ domain support to PCI interrupt
>> link for ACPI. Wi
address decoders, link bring-up, etc. - the
ACPI host bridge model relies on FW to carry out that initialization)
with ACPI - I would like to see the whole picture first.
Lorenzo
> Therefore, we introduce an stacked IRQ domain support to PCI interrupt
> link for ACPI. With this support, we ca
oot.c. It comes to be a problem
to make this kind of PCI INTx work under ACPI.
Therefore, we introduce an stacked IRQ domain support to PCI interrupt
link for ACPI. With this support, we can populate the ResourceSource
to refer to a device object that describes an interrupt controller.
That would
controller at the moment. Essentially, those designs are
> supported by inserting an extra interrupt controller between PCIe host
> and GIC and parse the topology in a DT-based PCI controller driver.
If I understand correctly, we previously ignored the Resource Source
field of an Extended Inter
controller between PCIe host
and GIC and parse the topology in a DT-based PCI controller driver.
As we turn to ACPI, All the PCIe hosts are described the same ID of
"PNP0A03" and share driver/acpi/pci_root.c. It comes to be a problem
to make this kind of PCI INTx work under ACPI.
Therefo
ACPI, All the PCIe hosts are described the same ID of
> "PNP0A03" and share driver/acpi/pci_root.c. It comes to be a problem
> to make this kind of PCI INTx work under ACPI.
>
> Therefore, we introduce an stacked IRQ domain support to PCI interrupt
> link for ACPI. With this s
controller between PCIe host
and GIC and parse the topology in a DT-based PCI controller driver.
As we turn to ACPI, All the PCIe hosts are described the same ID of
"PNP0A03" and share driver/acpi/pci_root.c. It comes to be a problem
to make this kind of PCI INTx work under ACPI.
Therefo
4.15-stable review patch. If anyone has any objections, please let me know.
--
From: Tom Lendacky
[ Upstream commit cfd092f2db8b4b6727e1c03ef68a7842e1023573 ]
After resuming from suspend, the PCI device support must re-enable the
interrupt setting so that interrupts are actua
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Tom Lendacky
[ Upstream commit cfd092f2db8b4b6727e1c03ef68a7842e1023573 ]
After resuming from suspend, the PCI device support must re-enable the
interrupt setting so that interrupts are actua
On Thu, 16 Mar 2017, Mason wrote:
> On 16/03/2017 18:47, Thomas Gleixner wrote:
> > On Thu, 16 Mar 2017, Mason wrote:
> >> I guess if two interrupts fire at the same time, we'll just take two
> >> separate exceptions?
> >
> > Wrong guess. That might work with level interrupts, but with other type
On 16/03/2017 18:47, Thomas Gleixner wrote:
> On Thu, 16 Mar 2017, Mason wrote:
>> I guess if two interrupts fire at the same time, we'll just take two
>> separate exceptions?
>
> Wrong guess. That might work with level interrupts, but with other types
> nothing will raise another exception. Shari
On Thu, 16 Mar 2017, Mason wrote:
> About shared ISRs. Are they supposed to return IRQ_HANDLED
> if and only if they handled something?
Every interrupt handler is supposed to return IRQ_NONE if it did not handle
it. That does not depend on shared or not. The handler does not know if
it's on a shar
On 16/03/2017 16:40, Mason wrote:
> Here is my current DT:
>
> msi0: msi@2e080 {
> compatible = "sigma,msi";
> reg = <0x2e04c 0x40>;
> interrupt-parent = <&irq0>;
> interrupts = <55 IRQ_TYPE_LEVE
Hello,
I am writing code for my platform's PCI Express controller.
I am stuck at the legacy PCI interrupt handling.
Interrupt requests are routed like this:
Cortex A9 MP <-- GIC(v1?) <-- system_intc <-- PCIe_root_complex
The PCIe root complex drives two interrupt signals to the
On Saturday 01 October 2016 19:49:17 Sinan Kaya wrote:
> On 9/30/2016 5:27 PM, Rafael J. Wysocki wrote:
> >>> >> What's the drawback, if any?
> >> >
> >> > I don't see any drawback to be honest.
> >
> > I'd go for it then, if Bjorn doesn't hate it.
>
> I posted a follow up patch a minute ago.
>
> [
Hi Ondrej,
On 10/3/2016 3:25 AM, Ondrej Zary wrote:
> On Monday 03 October 2016, Sinan Kaya wrote:
>> On 10/2/2016 12:53 PM, Ondrej Zary wrote:
Can we have some testing coverage? and eventually have tested-by?
>>>
>>> Works on two affected machines. More tests tomorrow.
>>
>> Thanks, apprecia
sary, use
"pci=use_crs" and report a bug
[0.056413] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14
15)
[0.056624] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14
15)
[0.056820] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 14
15)
[
On 10/2/2016 12:53 PM, Ondrej Zary wrote:
>> Can we have some testing coverage? and eventually have tested-by?
> Works on two affected machines. More tests tomorrow.
Thanks, appreciate the feedback. Looking forward to hear your other test
results.
--
Sinan Kaya
Qualcomm Datacenter Technologies,
r interrupt routing
[0.024507] PCI: Ignoring host bridge windows from ACPI; if necessary, use
"pci=use_crs" and report a bug
[0.031373] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14
15)
[0.031545] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14
On 9/30/2016 5:27 PM, Rafael J. Wysocki wrote:
>>> >> What's the drawback, if any?
>> >
>> > I don't see any drawback to be honest.
> I'd go for it then, if Bjorn doesn't hate it.
>
I posted a follow up patch a minute ago.
[PATCH 1/3] Revert "ACPI,PCI,IRQ: reduce static IRQ array size to 16"
[P
On 9/30/2016 5:27 PM, Rafael J. Wysocki wrote:
> On Fri, Sep 30, 2016 at 11:14 PM, Sinan Kaya wrote:
>> On 9/30/2016 5:04 PM, Rafael J. Wysocki wrote:
>
> I hope it makes sense now. I tend to skip details sometimes. Feel free to
> send more questions.
>>> Thanks for the information!
>>
On Fri, Sep 30, 2016 at 11:14 PM, Sinan Kaya wrote:
> On 9/30/2016 5:04 PM, Rafael J. Wysocki wrote:
>>> >
>>> > I hope it makes sense now. I tend to skip details sometimes. Feel free to
>>> > send more questions.
>> Thanks for the information!
>>
>> IIUC, basically, what you are proposing would b
On 9/30/2016 5:04 PM, Rafael J. Wysocki wrote:
>> >
>> > I hope it makes sense now. I tend to skip details sometimes. Feel free to
>> > send more questions.
> Thanks for the information!
>
> IIUC, basically, what you are proposing would be to restore the old
> penalizing method for IRQs in the 0-2
On Fri, Sep 30, 2016 at 10:24 PM, Sinan Kaya wrote:
> On 9/30/2016 3:39 PM, Rafael J. Wysocki wrote:
>>> how do we feel about increasing the ISA IRQ range to 256 so that
>>> > we are safe for all SCI interrupts?
>> I'm not sure how this is related to the problem at hand. Care to elaborate?
>>
>
>
On 9/30/2016 3:39 PM, Rafael J. Wysocki wrote:
>> how do we feel about increasing the ISA IRQ range to 256 so that
>> > we are safe for all SCI interrupts?
> I'm not sure how this is related to the problem at hand. Care to elaborate?
>
Sure, let me explain.
The code maintains a static array pe
On Fri, Sep 30, 2016 at 9:30 PM, Sinan Kaya wrote:
> Rafael, Bjorn;
>
> On 9/30/2016 11:56 AM, Ondrej Zary wrote:
It seems to work, at least on one machine.
>>> >
>>> > Ok, that comfirms my suspicion. We are having trouble detecting sci
>>> > interrupt type and we end up penalizing the wron
Rafael, Bjorn;
On 9/30/2016 11:56 AM, Ondrej Zary wrote:
>>> It seems to work, at least on one machine.
>> >
>> > Ok, that comfirms my suspicion. We are having trouble detecting sci
>> > interrupt type and we end up penalizing the wrong value.
>> >
>> > Can you try your other machines too?
> Wor
00-0xe5ff pref]
[0.089369] pci :01:00.0: reg 0x30: [mem 0x-0x pref]
[0.089510] pci :00:01.0: PCI bridge to [bus 01]
[0.089566] pci :00:01.0: bridge window [mem 0xe600-0xe7ff]
[0.089573] pci :00:01.0: bridge window [mem 0xe400-
On 2016-09-30 02:44, Ondrej Zary wrote:
On Friday 30 September 2016, Sinan Kaya wrote:
On 9/29/2016 2:00 PM, Ondrej Zary wrote:
>> The previous two patches were in the right direction.
>>
>> > Can we also get the same output from 4.6 kernel with the attached
>> > patch for the same machine you s
S4 S5)
[0.041283] ACPI: Using PIC for interrupt routing
[0.041393] PCI: Ignoring host bridge windows from ACPI; if necessary, use
"pci=use_crs" and report a bug
[0.054618] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14
15)
[0.054832] ACPI: PCI Interrupt Lin
On 9/29/2016 2:00 PM, Ondrej Zary wrote:
>> The previous two patches were in the right direction.
>> >
>> > Can we also get the same output from 4.6 kernel with the attached patch for
>> > the same machine you sent these?
> Here it is.
>
>> > Something about SCI still doesn't feel right.
>> >
>> >
reg 0x10: [mem 0xe600-0xe6ff]
[0.086077] pci :01:00.0: reg 0x14: [mem 0xe400-0xe5ff pref]
[0.086112] pci :01:00.0: reg 0x30: [mem 0x0000-0x pref]
[0.086268] pci :00:01.0: PCI bridge to [bus 01]
[ 0.086325] pci :00:01.0: bridge window [me
On 9/29/2016 12:48 PM, Ondrej Zary wrote:
>> Let's see the new set. If this doesn't work, I'll have to provide you with
>> > another patch to get the penalty counts again. The original debug aids
>> > patch may not apply after these.
> It boots but the IRQ problem still remains the same. See the at
000:01:00.0: reg 0x30: [mem 0x-0x pref]
[0.090078] pci :00:01.0: PCI bridge to [bus 01]
[0.090136] pci :00:01.0: bridge window [mem 0xe6000000-0xe7ff]
[0.090142] pci :00:01.0: bridge window [mem 0xe400-0xe5ff
pref]
[0.090153] pci_bus :00: o
On 9/29/2016 10:28 AM, Sinan Kaya wrote:
> + if (irq < ACPI_MAX_ISA_IRQS)
BTW, can you change this line to
if (link->irq.active < ACPI_MAX_ISA_IRQS)
after applying.
> + acpi_isa_irq_penalty[link->irq.active] +=
> + PIRQ_PENALTY
On 9/29/2016 10:18 AM, Wim Osterholt wrote:
> On Wed, Sep 28, 2016 at 07:38:41PM -0400, Sinan Kaya wrote:
>>
>> Can you try these patches on your machines please?
>
> I applied the included patches on vanilla 4.8-rc8 and my machine booted
> fine. (I saw a remark about SCSI interrupts, but I have n
On 9/29/2016 9:49 AM, Ondrej Zary wrote:
>> Ok, since I have not seen the full boot log I am guessing that isa api
>> > gets called before the link objects are initialized.
> Netconsole did not work (probably because it crashes too early?) and I don't
> have a null-modem cable.
>
Probably, this
On Wed, Sep 28, 2016 at 07:38:41PM -0400, Sinan Kaya wrote:
>
> Can you try these patches on your machines please?
I applied the included patches on vanilla 4.8-rc8 and my machine booted
fine. (I saw a remark about SCSI interrupts, but I have no SCSI.)
Regards, Wim.
311] Simple Boot Flag at 0x3a set to 0x1
[0.023335] clocksource: pit: mask: 0x max_cycles: 0xffff,
max_idle_ns: 1601818034827 ns
[0.023358] ACPI: bus type PCI registered
[0.030132] PCI: PCI BIOS revision 2.10 entry at 0xf10c0, last bus=1
[0.030136] PCI: Using configuration t
0XT-PIC pata_via
>
> (I'm moving between different machines through the day - these logs are
> from different machine than the last ones).
Can you try these patches on your machines please?
It doesn't even boot :(
Ok, since I have not seen the full boot log I am
XT-PIC uhci_hcd:usb1, uhci_hcd:usb2
> > 11: 0XT-PIC acpi, nvkm, eth0
> > 12:161XT-PIC i8042
> > 14: 4069XT-PIC pata_via
> > 15: 0XT-PIC pata_via
> >
> > (I'm moving between different machines through the
On 9/28/2016 3:23 PM, Ondrej Zary wrote:
> On Wednesday 28 September 2016 20:22:40 Sinan Kaya wrote:
>> On 9/28/2016 1:02 PM, Ondrej Zary wrote:
Thanks, It sounds like you have more than one machine with similar
> problems. Can you collect the log from the other machines with
> 4.
.0: reg 0x30: [mem 0x-0x pref]
[0.089775] pci :00:01.0: PCI bridge to [bus 01]
[0.089827] pci :00:01.0: bridge window [mem 0xe600-0xe7ff]
[0.089834] pci :00:01.0: bridge window [mem 0xe400-0xe5ff
pref]
[0.089845] pci_bus 000
On 9/28/2016 1:02 PM, Ondrej Zary wrote:
>> Thanks, It sounds like you have more than one machine with similar
>> > problems. Can you collect the log from the other machines with 4.8-rc8?
>> >
>> > and also a boot log with 4.6 kernel where things are working?
> The attached logs are from another ma
CPI: Added _OSI(Processor Device)
[0.022769] ACPI: Added _OSI(3.0 _SCP Extensions)
[0.022772] ACPI: Added _OSI(Processor Aggregator Device)
[0.024714] ACPI: Interpreter enabled
[0.024768] ACPI: (supports S0 S1 S4 S5)
[ 0.024771] ACPI: Using PIC for interrupt routing
[0.0248
On 9/28/2016 4:32 AM, Ondrej Zary wrote:
>>> OK
>>> > >
>>> > > Sinan, can you help, please?
>> >
>> > Sure, let's see what's going on. I was writing an email.
>> >
>> > Can we apply this and collect the kernel log? It also helps to see the
>> > kernel log from a working combination.
> This is from
6534] ACPI: Added _OSI(3.0 _SCP Extensions)
[0.036538] ACPI: Added _OSI(Processor Aggregator Device)
[0.040657] ACPI: Interpreter enabled
[0.040744] ACPI: (supports S0 S1 S4 S5)
[0.040753] ACPI: Using PIC for interrupt routing
[0.040871] PCI: Ignoring host bridge windows fro
On 9/27/2016 6:58 PM, Rafael J. Wysocki wrote:
>> :04 04 9bf16c388d23bb66e087809f069eafed18e46a8c
>> bcac95fb33ee834aec7d23eab9eb0dc5e330c68c M drivers
> OK
>
> Sinan, can you help, please?
>
>
Sure, let's see what's going on. I was writing an email.
Can we apply this and collec
; > On Sunday, September 25, 2016 03:12:05 PM Ondrej Zary wrote:
> > > > > Hello,
> > > > > I've upgraded kernel (Debian Squeeze - backports) from 4.6
> > > > > (4.6.4-1~bpo8+1) to 4.7 (4.7.2-1~bpo8+1) and IRQs stopped working
> > > > &
; Hello,
> > > > I've upgraded kernel (Debian Squeeze - backports) from 4.6
> > > > (4.6.4-1~bpo8+1) to 4.7 (4.7.2-1~bpo8+1) and IRQs stopped working
> > > > with error messages like this:
> > > >
> > > > ACPI: No IRQ available f
.6
> > > (4.6.4-1~bpo8+1) to 4.7 (4.7.2-1~bpo8+1) and IRQs stopped working with
> > > error messages like this:
> > >
> > > ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or
> > > acpi=off
> > >
> > > The sa
th
> > error messages like this:
> >
> > ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or
> > acpi=off
> >
> > The same thing appeared on two different machines. Is it a known/fixed
> > bug?
>
> Well, maybe.
>
> Can you
On Sunday, September 25, 2016 03:12:05 PM Ondrej Zary wrote:
> Hello,
> I've upgraded kernel (Debian Squeeze - backports) from 4.6 (4.6.4-1~bpo8+1)
> to 4.7 (4.7.2-1~bpo8+1) and IRQs stopped working with error messages like
> this:
>
> ACPI: No IRQ available for PCI Int
Hello,
I've upgraded kernel (Debian Squeeze - backports) from 4.6 (4.6.4-1~bpo8+1)
to 4.7 (4.7.2-1~bpo8+1) and IRQs stopped working with error messages like this:
ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
The same thing appeared on two different mac
Fix PCI interrupt routing on D-Link DSR-500N.
Signed-off-by: Aaro Koskinen
---
arch/mips/pci/pci-octeon.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/mips/pci/pci-octeon.c b/arch/mips/pci/pci-octeon.c
index c258cd4..308d051 100644
--- a/arch/mips/pci/pci-octeon.c
+++ b/arch/mips
Fix PCI interrupt routing on D-Link DSR-500N.
Signed-off-by: Aaro Koskinen
---
arch/mips/pci/pci-octeon.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/mips/pci/pci-octeon.c b/arch/mips/pci/pci-octeon.c
index c258cd4..308d051 100644
--- a/arch/mips/pci/pci-octeon.c
+++ b/arch/mips
Fix PCI interrupt map definition from 2 to 4 cells. Move
interrupt-map and interrupt-map-mask and clone interrupts
into the pcie child nodes.
Signed-off-by: Alessio Igor Bogani
---
This patch requires
https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-April/141980.html
to be applied cleanly
4.0-stable review patch. If anyone has any objections, please let me know.
--
From: Aaro Koskinen
Commit b083518c52ab75a345d668ca7fa41e530df08d51 upstream.
Fix PCI interrupt mapping for DSR1000N. This will get the PCI slot
interrupts working. The mapping is based on D-Link
Lost Garden wrote:
I'm writing a driver for DVB-C PCI receiving cards these days and
I found a tricky problem of interrupts. Since kernel-2.6.19 the
interrupt handlers get rid of "struct pt_regs*" argument and I think
it will be easy for me to modify the driver to fit for the recent
kernel.
I'm writing a driver for DVB-C PCI receiving cards these days and
I found a tricky problem of interrupts. Since kernel-2.6.19 the
interrupt handlers get rid of "struct pt_regs*" argument and I think
it will be easy for me to modify the driver to fit for the recent
kernel.
I simply delete th
On Wed, 19 Sep 2007, Frantisek Rysanek wrote:
> On IBM PC compatible hardware, there's always a risky "window of
> opportunity" that a shared edge-triggered interrupt line gets
> electrically re-triggered before your ISR manages to service all the
> devices and ACK the interrupt (I believe RTAI
On 19-09-2007 13:21, Frantisek Rysanek wrote:
> On 19 Sep 2007 at 12:14, Jarek Poplawski wrote:
>> On 18-09-2007 16:42, Rafael J. Wysocki wrote:
>>> Hm, edge-triggered interrupts cannot be shared, AFAIK.
>>>
>> Let's agree it's only a superstition...
>> http://en.wikipedia.org/wiki/Edge_triggered_i
On Wed, Sep 19, 2007 at 02:32:12PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, 19 September 2007 12:14, Jarek Poplawski wrote:
> > On 18-09-2007 16:42, Rafael J. Wysocki wrote:
> > ...
> > >
> > > Hm, edge-triggered interrupts cannot be shared, AFAIK.
> > >
> >
> > Let's agree it's only a su
On 19 Sep 2007 at 12:14, Jarek Poplawski wrote:
> On 18-09-2007 16:42, Rafael J. Wysocki wrote:
> > Hm, edge-triggered interrupts cannot be shared, AFAIK.
> >
> Let's agree it's only a superstition...
> http://en.wikipedia.org/wiki/Edge_triggered_interrupt
>
Superstition? Depends on how stringent
On Wednesday, 19 September 2007 12:14, Jarek Poplawski wrote:
> On 18-09-2007 16:42, Rafael J. Wysocki wrote:
> ...
> >
> > Hm, edge-triggered interrupts cannot be shared, AFAIK.
> >
>
> Let's agree it's only a superstition...
>
> http://en.wikipedia.org/wiki/Edge_triggered_interrupt
Well, if
On 18-09-2007 16:42, Rafael J. Wysocki wrote:
...
>
> Hm, edge-triggered interrupts cannot be shared, AFAIK.
>
Let's agree it's only a superstition...
http://en.wikipedia.org/wiki/Edge_triggered_interrupt
Regards,
Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
On Tue, 18 Sep 2007 [EMAIL PROTECTED] wrote:
> Sorted.
>
> A setting in the BIOS meant it was storing old configuration data.
> After disabling this option, it became a level triggered interrupt and
> everything now works!
>
> Thanks.
Good!
Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.
lt;[EMAIL PROTECTED]>
cc
18/09/2007 15:34 "Linux kernel"
Subject
Please resp
cc
> 18/09/2007 14:57 "Linux kernel"
>
> Subject
> Please respond to Re: PCI Interrupt
> "linux-os \(Dick
>
On Tuesday, 18 September 2007 15:57, linux-os (Dick Johnson) wrote:
>
> On Tue, 18 Sep 2007 [EMAIL PROTECTED] wrote:
>
> >
> > I have a CAN PCI card installed on my Ubuntu box.
> > I understand that PCI interrupts should be level rather than edge
> > triggered.
> >
> > The output of cat /proc/int
On Tue, Sep 18, 2007 at 03:08:46PM +0100, [EMAIL PROTECTED] wrote:
> The driver already does that ...
>
> result =
> request_irq(irq, can_pci_interrupt, SA_INTERRUPT | SA_SHIRQ,
> pDevice->au8IrqName, pDevice);
>
>
> Any other ideas?
Maybe the system thinks a ps2 mou
<[EMAIL PROTECTED]>
cc
18/09/2007 14:57 "Linux kernel"
Subject
Please r
On Tue, 18 Sep 2007 [EMAIL PROTECTED] wrote:
>
> I have a CAN PCI card installed on my Ubuntu box.
> I understand that PCI interrupts should be level rather than edge
> triggered.
>
> The output of cat /proc/interrupts is :-
>
> CPU0
> 0:1614601IO-APIC-edge timer
> 1:
I have a CAN PCI card installed on my Ubuntu box.
I understand that PCI interrupts should be level rather than edge
triggered.
The output of cat /proc/interrupts is :-
CPU0
0:1614601IO-APIC-edge timer
1:164IO-APIC-edge i8042
8: 3IO-APIC-edge r
Ganesh Venkatesan wrote:
Ben:
Have you checked if the BIOS on the super micro machine is the latest
and greatest. I have had interrupt routing issues very similar to the
one you are describing due to a BIOS Interrupt Routing issue. Moving
to newer BIOS fixed it.
A new BIOS didn't help. Super-Mi
Ben:
Have you checked if the BIOS on the super micro machine is the latest
and greatest. I have had interrupt routing issues very similar to the
one you are describing due to a BIOS Interrupt Routing issue. Moving
to newer BIOS fixed it.
ganesh.
On 3/24/05, Ben Greear <[EMAIL PROTECTED]> wrote:
For posterity's sake:
The problem is evidently a hardware problem, and I'll have to
return the board to the manufacturer so they can solder on another
part.
So, if you want to use 4-port NICs in slot-5 of the SuperMicro X6DVA-EG
board, then purchase the X6DVA-4G instead, as the X6DVA-EG will NOT wo
Lennert Buytenhek wrote:
On Wed, Mar 23, 2005 at 06:03:30PM -0800, Ben Greear wrote:
I have two 4-port e1000 NICs in the system, on a riser card.
How is the riser card wired? F.e. does it have a single edge
connector, and provides two PCI slots, or does it have a tiny
additional edge connector t
Daniel Egger <[EMAIL PROTECTED]> :
[...]
> NFS machines on the Gbit network will resume operation) I popped
> in the chp RealTek card (which caused some slight problems
> like permanent hangs and bad performance before) and everything
> works like a charm. Of course, after throwing in some extr
Daniel Egger wrote:
The card is still in the system and running, so if someone wants
me to run to more tests or diagnostic, please be my guest.
What does: ethtool -t eth0
show?
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this lis
On 24.03.2005, at 03:03, Ben Greear wrote:
When trying to send/receive traffic, I get TX watchdog timeouts. The
other
interfaces seem to work just fine.
No idea whether my problem is related but due to a broken motherboard
I had to switch from a SiS based Athlon board (ECS K7S5A) to a new
one whi
Lennert Buytenhek wrote:
On Wed, Mar 23, 2005 at 06:03:30PM -0800, Ben Greear wrote:
I have two 4-port e1000 NICs in the system, on a riser card.
How is the riser card wired? F.e. does it have a single edge
connector, and provides two PCI slots, or does it have a tiny
additional edge connector t
On Wed, Mar 23, 2005 at 06:03:30PM -0800, Ben Greear wrote:
> I have two 4-port e1000 NICs in the system, on a riser card.
How is the riser card wired? F.e. does it have a single edge
connector, and provides two PCI slots, or does it have a tiny
additional edge connector that routes REQ#/GNT#/IN
Ben Greear wrote:
I'm having a strange problem. I have an X6DVA motherboard
with dual 2.8Ghz emt-64 processors, 1GB of RAM, SATA HD, etc.
I tried kernel 2.6.11 which uses irq 26, and 2.6.10-1.770_FC2smp, which
maps the irq to 209 or something like that. Distribution is FC2, x86.
Kernel is compil
I: Transparent bridge - :00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EPA0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EPA0.PXHA._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EPA0.PXHB._PRT]
ACPI: PCI Interrupt Routing Ta
1 - 100 of 101 matches
Mail list logo
