(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 registe
> 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 beli
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
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 usb.
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.
>
Jeff 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 t
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 85
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, un
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'
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 (i
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?
Don
| 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?
Don
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
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: l
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
old
> > 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" v
| 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 b
| 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 b
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 interest
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
25 matches
Mail list logo
