Jesper Juhl wrote:
>
>Have you tried the suggestion given "... As a temporary workaround,
>the "pci=routeirq" argument..." ?
>You could also try the pci=noacpi boot option to see if that changes anything.
>
>
No, I missed that one. The machine works fine with either of those two
options. I
On 7/24/05, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> >> PCI: Using ACPI for IRQ routing
> >> ** PCI interrupts are no longer routed automatically. If this
> >> ** causes a device to stop working, it is probably because the
> >> ** driver failed to call pci_enable_device(). As a temporary
> >>
>> PCI: Using ACPI for IRQ routing
>> ** PCI interrupts are no longer routed automatically. If this
>> ** causes a device to stop working, it is probably because the
>> ** driver failed to call pci_enable_device(). As a temporary
>> ** workaround, the "pci=routeirq" argument restores the old
>>
On 7/24/05, Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Sorry about reporting this error so late but the machine in question had
> gone some time without upgrades.
>
> The problem I'm seeing is that IRQs stop working for one of the IRQ
> slots on the machine. It's only that slot, not the entire
Pierre Ossman wrote:
> ** PCI interrupts are no longer routed automatically. If this
> ** causes a device to stop working, it is probably because the
> ** driver failed to call pci_enable_device(). As a temporary
> ** workaround, the "pci=routeirq" argument restores the old
> ** behavior. If
Sorry about reporting this error so late but the machine in question had
gone some time without upgrades.
The problem I'm seeing is that IRQs stop working for one of the IRQ
slots on the machine. It's only that slot, not the entire IRQ, since the
two slots (it's a small machine) both get routed
Pierre Ossman wrote:
** PCI interrupts are no longer routed automatically. If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device(). As a temporary
** workaround, the pci=routeirq argument restores the old
** behavior. If this
On 7/24/05, Pierre Ossman [EMAIL PROTECTED] wrote:
Sorry about reporting this error so late but the machine in question had
gone some time without upgrades.
The problem I'm seeing is that IRQs stop working for one of the IRQ
slots on the machine. It's only that slot, not the entire IRQ,
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically. If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device(). As a temporary
** workaround, the pci=routeirq argument restores the old
** behavior.
On 7/24/05, Jan Engelhardt [EMAIL PROTECTED] wrote:
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically. If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device(). As a temporary
** workaround,
Jesper Juhl wrote:
Have you tried the suggestion given ... As a temporary workaround,
the pci=routeirq argument... ?
You could also try the pci=noacpi boot option to see if that changes anything.
No, I missed that one. The machine works fine with either of those two
options. I sent a
On Sunday 03 July 2005 15:16, Marko Kohtala wrote:
> irq 20: nobody cared (try booting with the "irqpoll" option)
I've filed a bug at kernel bugzilla so your report won't be lost.
See http://bugme.osdl.org/show_bug.cgi?id=4843
You can register at http://bugme.osdl.org/createaccount.cgi and add
> I've been having interrupt problems. 2.6.12 worked fine, but
> soon after it got broken and was still broken just now that I
> checked git version.
>
> Interrupts get somehow misrouted.
>
> Here is a part from the syslog showing the problem:
>
> Jul 3 13:17:09 kohtala kernel: USB Universal
I've been having interrupt problems. 2.6.12 worked fine, but
soon after it got broken and was still broken just now that I
checked git version.
Interrupts get somehow misrouted.
Here is a part from the syslog showing the problem:
Jul 3 13:17:09 kohtala kernel: USB Universal Host
On Sunday 03 July 2005 15:16, Marko Kohtala wrote:
irq 20: nobody cared (try booting with the irqpoll option)
I've filed a bug at kernel bugzilla so your report won't be lost.
See http://bugme.osdl.org/show_bug.cgi?id=4843
You can register at http://bugme.osdl.org/createaccount.cgi and add
I noticed that there have been updates to epic100 again and just wanted
to note that the problem remains:
2.4.2-ac3 still crashes, but it works fine when I use the epic100.c
from 2.4.0-test9, which was the last working version for me.
Arnd <><
On Thu, 15 Feb 2001, ARND BERGMANN wrote:
> Sorry
I noticed that there have been updates to epic100 again and just wanted
to note that the problem remains:
2.4.2-ac3 still crashes, but it works fine when I use the epic100.c
from 2.4.0-test9, which was the last working version for me.
Arnd
On Thu, 15 Feb 2001, ARND BERGMANN wrote:
Sorry for
Sorry for the delay, I could not get physical access to the machine
for the last days.
I was able to do some more testing today and found this:
- The problem is not the IRQ /sharing/, after getting rid of all the
other PCI cards, the problem was still there.
- The only thing that seems to have
Sorry for the delay, I could not get physical access to the machine
for the last days.
I was able to do some more testing today and found this:
- The problem is not the IRQ /sharing/, after getting rid of all the
other PCI cards, the problem was still there.
- The only thing that seems to have
ARND BERGMANN <[EMAIL PROTECTED]> écrit :
[...]
> > > > > Working epic100 drivers:
> > > > > - 2.4.0
> > > > > - 2.4.0-ac9
> > > >
> > > > Could you give a look at ac12 (fine here) ?
> > > >
> > > No, does not work, same problem.
> >
> > The modifications between ac9 and ac12 come from the
ARND BERGMANN [EMAIL PROTECTED] crit :
[...]
Working epic100 drivers:
- 2.4.0
- 2.4.0-ac9
Could you give a look at ac12 (fine here) ?
No, does not work, same problem.
The modifications between ac9 and ac12 come from the new DMA
mapping.
What about
(cc's shortened, not to trash Linus et al)
On Thu, 1 Feb 2001, Robert Siemer wrote:
> Is it possible to directly ask the 'IRQ-router' (namely the
> ISA-bridge) for what it is set up for? - I mean which IRQ is routed to
> what without the help of the BIOS?
It's written in the PCI config
> From: Martin Diehl [mailto:[EMAIL PROTECTED]]
...
> Linus' patch helps you, because it makes us trusting the
> device's config
> space over the routing table. Probably a good idea as long as BIOS'es
> wouldn't start to set wrong values in config space too...
...
> in fact vanilla 2.4.0 did
On Tue, 30 Jan 2001, Robert Siemer wrote:
> > Below is the updated patch. It should handle both (0x01/0x41
> > like) mappings. I can (and did) only test the 0x01 case.
> > USBIRQ routing (0x62) supported, IDE/ACPI/DAQ untouched.
>
> I don't really understand your note above, but your patch
On Tue, 30 Jan 2001, Robert Siemer wrote:
Below is the updated patch. It should handle both (0x01/0x41
like) mappings. I can (and did) only test the 0x01 case.
USBIRQ routing (0x62) supported, IDE/ACPI/DAQ untouched.
I don't really understand your note above, but your patch alone does
From: Martin Diehl [mailto:[EMAIL PROTECTED]]
...
Linus' patch helps you, because it makes us trusting the
device's config
space over the routing table. Probably a good idea as long as BIOS'es
wouldn't start to set wrong values in config space too...
...
in fact vanilla 2.4.0 did believe
(cc's shortened, not to trash Linus et al)
On Thu, 1 Feb 2001, Robert Siemer wrote:
Is it possible to directly ask the 'IRQ-router' (namely the
ISA-bridge) for what it is set up for? - I mean which IRQ is routed to
what without the help of the BIOS?
It's written in the PCI config registers
From: Martin Diehl <[EMAIL PROTECTED]>
> On Mon, 29 Jan 2001, Linus Torvalds wrote:
> Below is the updated patch. It should handle both (0x01/0x41
> like) mappings. I can (and did) only test the 0x01 case.
> USBIRQ routing (0x62) supported, IDE/ACPI/DAQ untouched.
I don't really understand your
hmmm, would these sis-related pirq problems be related to the current
problems lots of people with a via chipset (at least the apollo pro 133a
chipset) and an smp-enabled kernel are seeing? currently, people with
this chipset and an smp-enabled kernel have to disable apic if they wish
to use
On Mon, 29 Jan 2001, Linus Torvalds wrote:
> reg = pirq;
> if (reg < 5)
> reg += 0x40;
or adding the 0x41..0x44 cases to the switch statement in my patch?
> > BTW: I was wondering, why we did not update the PCI_INTERRUPT_LINE in
>
> I would prefer _not_ to see this.
Garzik <[EMAIL PROTECTED]>
Cc: Linus Torvalds <[EMAIL PROTECTED]>,
Robert Siemer <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: PCI IRQ routing problem in 2.4.0
On Mon, 29 Jan 2001, Jeff Garzik wrote:
> And what what we're seeing in this thread, it looks like there are
&
On Mon, 29 Jan 2001, Martin Diehl wrote:
>
> Right, seems the 0x41/0x01 thing. I have the 0x01 case with SiS 85C503
> router rev. 01. Hopefully the 0x41 boards have a different revision. My
> fear however is, this is due to BIOS implementation of the routing table.
>
> Using the docs of the
From: Linus Torvalds <[EMAIL PROTECTED]>
> On Mon, 29 Jan 2001, Robert Siemer wrote:
> >
> > Further I always see '09' in the Configuration Space at Interrupt_Line
> > (0x3c) for the 00:01.2 USB Controller. But 2.4.0 says:
> > Interrupt: pin A routed to IRQ 12
> > while 2.4.0-test9 states:
> >
On Mon, 29 Jan 2001, Martin Diehl wrote:
> I've the documentation for the SiS 5591/95 chipset which provides
> IRQ-routing using the 85C503 ISA bridge function function. This is
> the same vendor/device id as the pirq_sis*() rely on. According to this
> datasheet the pirq_sis*() thing is wrong,
On Mon, 29 Jan 2001, Martin Diehl wrote:
I've the documentation for the SiS 5591/95 chipset which provides
IRQ-routing using the 85C503 ISA bridge function function. This is
the same vendor/device id as the pirq_sis*() rely on. According to this
datasheet the pirq_sis*() thing is wrong,
From: Linus Torvalds [EMAIL PROTECTED]
On Mon, 29 Jan 2001, Robert Siemer wrote:
Further I always see '09' in the Configuration Space at Interrupt_Line
(0x3c) for the 00:01.2 USB Controller. But 2.4.0 says:
Interrupt: pin A routed to IRQ 12
while 2.4.0-test9 states:
Interrupt:
On Mon, 29 Jan 2001, Martin Diehl wrote:
Right, seems the 0x41/0x01 thing. I have the 0x01 case with SiS 85C503
router rev. 01. Hopefully the 0x41 boards have a different revision. My
fear however is, this is due to BIOS implementation of the routing table.
Using the docs of the 85C503
[EMAIL PROTECTED]
Cc: Linus Torvalds [EMAIL PROTECTED],
Robert Siemer [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: PCI IRQ routing problem in 2.4.0
On Mon, 29 Jan 2001, Jeff Garzik wrote:
And what what we're seeing in this thread, it looks like there are
two different types of SiS link
On Mon, 29 Jan 2001, Linus Torvalds wrote:
reg = pirq;
if (reg 5)
reg += 0x40;
or adding the 0x41..0x44 cases to the switch statement in my patch?
BTW: I was wondering, why we did not update the PCI_INTERRUPT_LINE in
I would prefer _not_ to see this.
Why?
hmmm, would these sis-related pirq problems be related to the current
problems lots of people with a via chipset (at least the apollo pro 133a
chipset) and an smp-enabled kernel are seeing? currently, people with
this chipset and an smp-enabled kernel have to disable apic if they wish
to use
From: Martin Diehl [EMAIL PROTECTED]
On Mon, 29 Jan 2001, Linus Torvalds wrote:
Below is the updated patch. It should handle both (0x01/0x41
like) mappings. I can (and did) only test the 0x01 case.
USBIRQ routing (0x62) supported, IDE/ACPI/DAQ untouched.
I don't really understand your note
On Mon, 29 Jan 2001, Robert Siemer wrote:
>
> Further I always see '09' in the Configuration Space at Interrupt_Line
> (0x3c) for the 00:01.2 USB Controller. But 2.4.0 says:
> Interrupt: pin A routed to IRQ 12
> while 2.4.0-test9 states:
> Interrupt: pin A routed to IRQ 9
Ahhah!
I bet
On Mon, 29 Jan 2001, Aaron Tiensivu wrote:
> | Which one was it you got a PIRQ conflict for before? as it te device at
> | 00:01.00 with the strange "0x62" entry?
>
> Yes.
You've got the pirq setup from hell.
Mind doing that "dump_pirq" thing, preferably run on an _unmodified_ 2.4.0
kernel
From: Linus Torvalds <[EMAIL PROTECTED]>
> On Mon, 29 Jan 2001, Robert Siemer wrote:
> > >
> > > and see if that changes the behaviour.
> >
> > It doesn't. A diff from the kernel output is following. Maybe it
> > helps...
>
> Actually, this looks like it _did_ fix something - now the kernel
| Which one was it you got a PIRQ conflict for before? as it te device at
| 00:01.00 with the strange "0x62" entry?
Yes.
| How about you try adding the line
| pirq = (pirq-1) & 3;
| at the top of both pirq_sis_get() and pirq_sis_set() (with my "alternate"
| SiS routines). What happens then?
| Which one was it you got a PIRQ conflict for before? as it te device at
| 00:01.00 with the strange "0x62" entry?
Yes.
| How about you try adding the line
| pirq = (pirq-1) & 3;
| at the top of both pirq_sis_get() and pirq_sis_set() (with my "alternate"
| SiS routines). What happens then?
On Mon, 29 Jan 2001, Robert Siemer wrote:
> >
> > and see if that changes the behaviour.
>
> It doesn't. A diff from the kernel output is following. Maybe it
> helps...
Actually, this looks like it _did_ fix something - now the kernel no
longer thinks there is a IRQ routing conflict, so
From: Linus Torvalds <[EMAIL PROTECTED]>
> On Mon, 29 Jan 2001, Robert Siemer wrote:
> (...) that's really interesting..
>
> > Device 00:01.0 (slot 0): ISA bridge
> > INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
> > INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
> > INTC:
On Sun, 28 Jan 2001, Tim Hockin wrote:
>
> In reading the PIRQ specs, and making it work for our board, I thought
> about this. PIRQ states that link is chipset-dependant. No chipset that I
> have seen specifies what link should be. So, as this case demonstrates, it
> may be 'A' - the value
On Mon, 29 Jan 2001, Aaron Tiensivu wrote:
>
> My ASUS SP97-V complains about PIRQ conflicts so I gave this a whirl
> (It is SiS 5598 based)
Your pirq values are different - they are in the 0x41-0x44 range, like the
old SiS router code assumes. Except for one that has value 0x62, which the
> > Device 00:01.0 (slot 0): ISA bridge
> > INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
> > INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
> > INTC: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
> > INTD: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
>
> Your "link"
| Your "link" values are in the range 1-4. Which makes perfect sense, but
| that's absolutely _not_ what the Linux SiS routing code expects (the code
| seems to expect them to be ASCII 'A' - 'D').
| It looks very much like "pirq_sis_get()" and "pirq_sis_set()" in
| arch/i386/kernel/pci-irq.c are
| Your "link" values are in the range 1-4. Which makes perfect sense, but
| that's absolutely _not_ what the Linux SiS routing code expects (the code
| seems to expect them to be ASCII 'A' - 'D').
| It looks very much like "pirq_sis_get()" and "pirq_sis_set()" in
| arch/i386/kernel/pci-irq.c are
On Mon, 29 Jan 2001, Robert Siemer wrote:
> From: Linus Torvalds <[EMAIL PROTECTED]>
>
> > Another one..
>
> > Robert, can you get the dump_pirq script from the pcmcia_cs package
> > and send the output to us?
>
> ...it seems to reflect my settings in the bios:
No, but that's really
From: Linus Torvalds <[EMAIL PROTECTED]>
> Another one..
> Robert, can you get the dump_pirq script from the pcmcia_cs package
> and send the output to us?
...it seems to reflect my settings in the bios:
Interrupt routing table found at address 0xf0a50:
Version 1.0, size 0x0080
Interrupt
Hi Martin!
While moving from 2.4.0-test9 to 2.4.0 I got the following problem:
Linux thinks my usb controller is on IRQ 12 instead of IRQ 9.
The 'BIOS box' (on boot) still states that usb is on IRQ 9.
Under test9 pci-irq-behaviour was okay for me, but with 2.4.0 I cant
load the usb-modules (the
Hi Martin!
While moving from 2.4.0-test9 to 2.4.0 I got the following problem:
Linux thinks my usb controller is on IRQ 12 instead of IRQ 9.
The 'BIOS box' (on boot) still states that usb is on IRQ 9.
Under test9 pci-irq-behaviour was okay for me, but with 2.4.0 I cant
load the usb-modules (the
From: Linus Torvalds [EMAIL PROTECTED]
Another one..
Robert, can you get the dump_pirq script from the pcmcia_cs package
and send the output to us?
...it seems to reflect my settings in the bios:
Interrupt routing table found at address 0xf0a50:
Version 1.0, size 0x0080
Interrupt
On Mon, 29 Jan 2001, Robert Siemer wrote:
From: Linus Torvalds [EMAIL PROTECTED]
Another one..
Robert, can you get the dump_pirq script from the pcmcia_cs package
and send the output to us?
...it seems to reflect my settings in the bios:
No, but that's really interesting..
| Your "link" values are in the range 1-4. Which makes perfect sense, but
| that's absolutely _not_ what the Linux SiS routing code expects (the code
| seems to expect them to be ASCII 'A' - 'D').
| It looks very much like "pirq_sis_get()" and "pirq_sis_set()" in
| arch/i386/kernel/pci-irq.c are
| Your "link" values are in the range 1-4. Which makes perfect sense, but
| that's absolutely _not_ what the Linux SiS routing code expects (the code
| seems to expect them to be ASCII 'A' - 'D').
| It looks very much like "pirq_sis_get()" and "pirq_sis_set()" in
| arch/i386/kernel/pci-irq.c are
Device 00:01.0 (slot 0): ISA bridge
INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
INTC: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
INTD: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
Your "link" values are
On Mon, 29 Jan 2001, Aaron Tiensivu wrote:
My ASUS SP97-V complains about PIRQ conflicts so I gave this a whirl
(It is SiS 5598 based)
Your pirq values are different - they are in the 0x41-0x44 range, like the
old SiS router code assumes. Except for one that has value 0x62, which the
old
On Sun, 28 Jan 2001, Tim Hockin wrote:
In reading the PIRQ specs, and making it work for our board, I thought
about this. PIRQ states that link is chipset-dependant. No chipset that I
have seen specifies what link should be. So, as this case demonstrates, it
may be 'A' - the value the
From: Linus Torvalds [EMAIL PROTECTED]
On Mon, 29 Jan 2001, Robert Siemer wrote:
(...) that's really interesting..
Device 00:01.0 (slot 0): ISA bridge
INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
INTC: link 0x03,
On Mon, 29 Jan 2001, Robert Siemer wrote:
and see if that changes the behaviour.
It doesn't. A diff from the kernel output is following. Maybe it
helps...
Actually, this looks like it _did_ fix something - now the kernel no
longer thinks there is a IRQ routing conflict, so it does
| Which one was it you got a PIRQ conflict for before? as it te device at
| 00:01.00 with the strange "0x62" entry?
Yes.
| How about you try adding the line
| pirq = (pirq-1) 3;
| at the top of both pirq_sis_get() and pirq_sis_set() (with my "alternate"
| SiS routines). What happens then?
| Which one was it you got a PIRQ conflict for before? as it te device at
| 00:01.00 with the strange "0x62" entry?
Yes.
| How about you try adding the line
| pirq = (pirq-1) 3;
| at the top of both pirq_sis_get() and pirq_sis_set() (with my "alternate"
| SiS routines). What happens then?
From: Linus Torvalds [EMAIL PROTECTED]
On Mon, 29 Jan 2001, Robert Siemer wrote:
and see if that changes the behaviour.
It doesn't. A diff from the kernel output is following. Maybe it
helps...
Actually, this looks like it _did_ fix something - now the kernel no
longer
On Mon, 29 Jan 2001, Aaron Tiensivu wrote:
| Which one was it you got a PIRQ conflict for before? as it te device at
| 00:01.00 with the strange "0x62" entry?
Yes.
You've got the pirq setup from hell.
Mind doing that "dump_pirq" thing, preferably run on an _unmodified_ 2.4.0
kernel (ie
On Mon, 29 Jan 2001, Robert Siemer wrote:
Further I always see '09' in the Configuration Space at Interrupt_Line
(0x3c) for the 00:01.2 USB Controller. But 2.4.0 says:
Interrupt: pin A routed to IRQ 12
while 2.4.0-test9 states:
Interrupt: pin A routed to IRQ 9
Ahhah!
I bet it's the
Hello, all!
I am having some problems with de delivery of the USB irq.
Without the kernel-option "noapic", it seems, they just never make it to the
kernel.
I tried running with mps=1.1, mps=1.4, PNP OS=y/n, but that doesn't help...
I am also running windoze 2000 on this machine, and that sets
Hello, all!
I am having some problems with de delivery of the USB irq.
Without the kernel-option "noapic", it seems, they just never make it to the
kernel.
I tried running with mps=1.1, mps=1.4, PNP OS=y/n, but that doesn't help...
I am also running windoze 2000 on this machine, and that sets
I am having problems with something that looks like a PCI IRQ routing
problem. Everything worked just fine up until test12-pre7. Test12-pre8 did
not even boot, it hung when initializing the SCSI adapter.
Everything after that (including test12) booted successfully, but crashed when
I loaded
I am having problems with something that looks like a PCI IRQ routing
problem. Everything worked just fine up until test12-pre7. Test12-pre8 did
not even boot, it hung when initializing the SCSI adapter.
Everything after that (including test12) booted successfully, but crashed when
I loaded
't
> enable smp or when i disable apic on smp-enabled kernels. he believes
> that we're seeing a pci irq routing problem and that i should contact
> martin mares about this problem. (i've written him a couple times,
> but have heard nothing, so i figure he's either away, busy, or what
seeing a pci irq routing problem and that i should contact martin mares
about this problem. (i've written him a couple times, but have heard
nothing, so i figure he's either away, busy, or whatnot and i thought
i'd try lkml for help.)
i have an ethernet card on my system and it shares an irq
seeing a pci irq routing problem and that i should contact martin mares
about this problem. (i've written him a couple times, but have heard
nothing, so i figure he's either away, busy, or whatnot and i thought
i'd try lkml for help.)
i have an ethernet card on my system and it shares an irq
or when i disable apic on smp-enabled kernels. he believes
that we're seeing a pci irq routing problem and that i should contact
martin mares about this problem. (i've written him a couple times,
but have heard nothing, so i figure he's either away, busy, or whatnot
and i thought i'd try lkml
79 matches
Mail list logo
