[ Upstream commit ea094d53580f40c2124cef3d072b73b2425e7bfd ]
In pcibios_irq_init(), the PCI IRQ routing table 'pirq_table' is first
found through pirq_find_routing_table(). If the table is not found and
CONFIG_PCI_BIOS is defined, the table is then allocated in
pcibios_get_irq_rou
[ Upstream commit ea094d53580f40c2124cef3d072b73b2425e7bfd ]
In pcibios_irq_init(), the PCI IRQ routing table 'pirq_table' is first
found through pirq_find_routing_table(). If the table is not found and
CONFIG_PCI_BIOS is defined, the table is then allocated in
pcibios_get_irq_rou
[ Upstream commit ea094d53580f40c2124cef3d072b73b2425e7bfd ]
In pcibios_irq_init(), the PCI IRQ routing table 'pirq_table' is first
found through pirq_find_routing_table(). If the table is not found and
CONFIG_PCI_BIOS is defined, the table is then allocated in
pcibios_get_irq_rou
[ Upstream commit ea094d53580f40c2124cef3d072b73b2425e7bfd ]
In pcibios_irq_init(), the PCI IRQ routing table 'pirq_table' is first
found through pirq_find_routing_table(). If the table is not found and
CONFIG_PCI_BIOS is defined, the table is then allocated in
pcibios_get_irq_rou
[ Upstream commit ea094d53580f40c2124cef3d072b73b2425e7bfd ]
In pcibios_irq_init(), the PCI IRQ routing table 'pirq_table' is first
found through pirq_find_routing_table(). If the table is not found and
CONFIG_PCI_BIOS is defined, the table is then allocated in
pcibios_get_irq_rou
From: Wenwen Wang
[ Upstream commit ea094d53580f40c2124cef3d072b73b2425e7bfd ]
In pcibios_irq_init(), the PCI IRQ routing table 'pirq_table' is first
found through pirq_find_routing_table(). If the table is not found and
CONFIG_PCI_BIOS is defined, the table is then al
Krzysztof Halasa wrote:
> Udo van den Heuvel <[EMAIL PROTECTED]> writes:
>
>> I have DN19 and DN20 now and it doesn't work.
>> Only because the INT mapping on the riser is not right?
>
> Yes. I assume DN20 works, only DN19 has problems.
Well, today I tried the same VIA motherboard (EN12000) with
Krzysztof Halasa wrote:
> Udo van den Heuvel <[EMAIL PROTECTED]> writes:
>
>> I will try a different case with a different dual PCI riser card soon.
>> This Morex riser has DN20-31 or so, so more options.
>
> OTOH I wonder how do they use DN 21-31? The board uses lines AD11 to AD31
> (21 lines) f
Udo van den Heuvel <[EMAIL PROTECTED]> writes:
> Description VIA Dual PCI Riser
> The EXT-PCI is a PCI riser card which expands a PCI slot into two PCI slots.
> EXT-PCI slot 1 (lower slot) uses the system resources (Device ID, INT)
> of the PCI slot of the motherboard.
Yep. ID 20, INT D (chipset
Udo van den Heuvel <[EMAIL PROTECTED]> writes:
> I have DN19 and DN20 now and it doesn't work.
> Only because the INT mapping on the riser is not right?
Yes. I assume DN20 works, only DN19 has problems.
> http://www.morex.com.tw/drawing/MAR122-J%20Drawing.pdf shows some IDSEL
> jumper with ADxx
Krzysztof Halasa wrote:
> Udo van den Heuvel <[EMAIL PROTECTED]> writes:
>
>> I will try a different case with a different dual PCI riser card soon.
>> This Morex riser has DN20-31 or so, so more options.
>
> OTOH I wonder how do they use DN 21-31? The board uses lines AD11 to AD31
> (21 lines) f
Krzysztof Halasa wrote:
> Udo van den Heuvel <[EMAIL PROTECTED]> writes:
>
>> I will try a different case with a different dual PCI riser card soon.
>> This Morex riser has DN20-31 or so, so more options.
>> Could this help solve my irq issue? (try 4 consecutive DNs until I have
>> the right mappi
Udo van den Heuvel <[EMAIL PROTECTED]> writes:
> I will try a different case with a different dual PCI riser card soon.
> This Morex riser has DN20-31 or so, so more options.
OTOH I wonder how do they use DN 21-31? The board uses lines AD11 to AD31
(21 lines) for selecting devices #0 - #20. 32-bi
Hello,
Udo van den Heuvel <[EMAIL PROTECTED]> writes:
> I will try a different case with a different dual PCI riser card soon.
> This Morex riser has DN20-31 or so, so more options.
> Could this help solve my irq issue? (try 4 consecutive DNs until I have
> the right mapping?)
I don't think so.
On Fri, Feb 23, 2007 at 04:45:45PM +0100, Udo van den Heuvel wrote:
> Small update:
>
> I will try a different case with a different dual PCI riser card soon.
> This Morex riser has DN20-31 or so, so more options.
> Could this help solve my irq issue? (try 4 consecutive DNs until I have
> the righ
Hello,
Small update:
I will try a different case with a different dual PCI riser card soon.
This Morex riser has DN20-31 or so, so more options.
Could this help solve my irq issue? (try 4 consecutive DNs until I have
the right mapping?)
Kind regrads,
Udo
-
To unsubscribe from this list: send the
Alistair John Strachan <[EMAIL PROTECTED]> writes:
> One warning to you though, I found the riser to be pretty flaky, causing
> bizarre lockups and periodic crashes of Linux. Maybe this is a Linux
> bug, but
> it really didn't seem like it.
I don't know how it could be a Linux bug.
Perhaps mec
[EMAIL PROTECTED] (Lennart Sorensen) writes:
> Well someone said the VIA uses INTA for the DN19 on their riser card,
> although is that INTA from the CPUs point of view or INTA from the slot
> the riser card is plugged into?
CPU/chipset it seems.
>> Device# IDSEL INT (first)
>> 0x08A1
On Wednesday 21 February 2007 22:40, Lennart Sorensen wrote:
> On Wed, Feb 21, 2007 at 10:35:05PM +0100, Krzysztof Halasa wrote:
> > Do you mean both slots on the riser card? No, they have to be rotated.
> >
> > Given the table from the manual:
> > > The IRQ (interrupt request line) are hardware li
On Wed, Feb 21, 2007 at 10:35:05PM +0100, Krzysztof Halasa wrote:
> Do you mean both slots on the riser card? No, they have to be rotated.
>
> Given the table from the manual:
>
> > The IRQ (interrupt request line) are hardware lines over which devices
> > can send interrupt signals to the microp
On Wed, Feb 21, 2007 at 07:11:06PM +0100, Udo van den Heuvel wrote:
> BTW:
>
> Is the situation, with default DN setting of 19 as displayed below,
> `normal` w.r.t. interrupts?
> I mean: Both the DVB card with DN19 and the Unichrome Pro video adapter
> have the same irq although they are on differ
On Wed, Feb 21, 2007 at 01:11:12AM +0100, Krzysztof Halasa wrote:
> [EMAIL PROTECTED] (Lennart Sorensen) writes:
>
> > Via has a dual pci-ext card. See EXT-PCI at
> > http://www.via.com.tw/en/products/mainboards/accessories.jsp
>
> Right, and they say it's compatible with "EPIA mini-ITX family".
On Wed, Feb 21, 2007 at 10:24:28AM +0100, Udo van den Heuvel wrote:
> Udo van den Heuvel wrote:
> > Any ideas about how to proceed?
> > What to test?
>
> I found some info on the VIA dual PCI extender card at
> http://www.itx-warehouse.co.uk/Product.aspx?ProductID=410.
> The text says:
>
> The EX
Udo van den Heuvel <[EMAIL PROTECTED]> writes:
> Is the situation, with default DN setting of 19 as displayed below,
> `normal` w.r.t. interrupts?
> I mean: Both the DVB card with DN19 and the Unichrome Pro video adapter
> have the same irq although they are on different busses.
It's normal (and
Udo van den Heuvel <[EMAIL PROTECTED]> writes:
> But the IRQ for the DVB-T card doesn't work.
That's because the card drives incorrect INT line. The system (BIOS,
Linux) thinks the card would drive INT_D (as seen at the MB PCI slot)
and and card drives (its INT_A) INT_B.
> I would need to test t
On Wed, Feb 21, 2007 at 03:59:51PM +0100, Udo van den Heuvel wrote:
> But the IRQ for the DVB-T card doesn't work.
> I would need to test the DVB-T card alone to be sure it has working IRQ.
> If so, what would be the conclusion?
Well the BIOS makes an assumption about the irq routing on the board,
Lennart Sorensen wrote:
> On Wed, Feb 21, 2007 at 10:24:28AM +0100, Udo van den Heuvel wrote:
>> Udo van den Heuvel wrote:
>> So, if not (as in my situation) how can I find out what is wrong?
>> Or find out if the BIOS works OK with the card?
>> How can I verify that the correct routing for the IRQ
BTW:
Is the situation, with default DN setting of 19 as displayed below,
`normal` w.r.t. interrupts?
I mean: Both the DVB card with DN19 and the Unichrome Pro video adapter
have the same irq although they are on different busses.
(...)
00:13.0 Multimedia controller: Philips Semiconductors SAA7146
Krzysztof Halasa wrote:
> Udo van den Heuvel <[EMAIL PROTECTED]> writes:
>
>> So if my non-VIA riser card can use DN 19 and also INT_A things should work?
>
> That INT_A may be INT_A from their (motherboard) point of view, but
> the riser card doesn't know about that, it only knows INTs as seen
>
Udo van den Heuvel <[EMAIL PROTECTED]> writes:
> So if my non-VIA riser card can use DN 19 and also INT_A things should work?
That INT_A may be INT_A from their (motherboard) point of view, but
the riser card doesn't know about that, it only knows INTs as seen
at its PCI edge connector (so this I
Udo van den Heuvel wrote:
> Any ideas about how to proceed?
> What to test?
I found some info on the VIA dual PCI extender card at
http://www.itx-warehouse.co.uk/Product.aspx?ProductID=410.
The text says:
The EXT-PCI is a PCI riser card which expands a PCI slot into two PCI slots.
EXT-PCI slot 1
[EMAIL PROTECTED] (Lennart Sorensen) writes:
> Via has a dual pci-ext card. See EXT-PCI at
> http://www.via.com.tw/en/products/mainboards/accessories.jsp
Right, and they say it's compatible with "EPIA mini-ITX family".
That means the mappings I just outlined should apply to all of them.
BTW: an
Udo van den Heuvel <[EMAIL PROTECTED]> writes:
> saa7146: found saa7146 @ mem f896a000 (revision 1, irq 145) (0x153b,0x1157).
> saa7146: found saa7146 @ mem f89e6000 (revision 1, irq 153) (0x153b,0x1155).
IO-APICs can do such things...
Ok, I have experimented a bit with my old unused EPIA-M 600
On Tue, Feb 20, 2007 at 09:47:48PM +0100, Krzysztof Halasa wrote:
> Udo van den Heuvel <[EMAIL PROTECTED]> writes:
>
> > Yes, VIA Epia EN12000.
> > Interesting to check the riser card.
>
> Unfortunately it turns out it's single slot only.
Via has a dual pci-ext card. See EXT-PCI at
http://www.v
Udo van den Heuvel <[EMAIL PROTECTED]> writes:
> Yes, VIA Epia EN12000.
> Interesting to check the riser card.
Unfortunately it turns out it's single slot only.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTEC
On Tuesday 20 February 2007 15:44, you wrote:
> Alistair John Strachan wrote:
> > On Tuesday 20 February 2007 04:17, Udo van den Heuvel wrote:
> >> Krzysztof Halasa wrote:
> >>> Is it a VIA ITX board? I think I have VIA's riser card somewhere,
> >>> could check what it does.
> >>
> >> Yes, VIA Epia
Alistair John Strachan wrote:
> On Tuesday 20 February 2007 04:17, Udo van den Heuvel wrote:
>> Krzysztof Halasa wrote:
>>> Is it a VIA ITX board? I think I have VIA's riser card somewhere,
>>> could check what it does.
>> Yes, VIA Epia EN12000.
>> Interesting to check the riser card.
>
> Just be
On Tuesday 20 February 2007 04:17, Udo van den Heuvel wrote:
> Krzysztof Halasa wrote:
> > Udo van den Heuvel <[EMAIL PROTECTED]> writes:
> >> At the bottom I added a dmesg output of the kernel after boot.
> >> I more or less know that irq 20 for the DVB-S card (saa7146 (1)) is
> >> 'working'. I kn
Krzysztof Halasa wrote:
> Udo van den Heuvel <[EMAIL PROTECTED]> writes:
>
>> At the bottom I added a dmesg output of the kernel after boot.
>> I more or less know that irq 20 for the DVB-S card (saa7146 (1)) is
>> 'working'. I know that irq 16 for saa7146 (0) (DVB-T) is not working for
>> i2c alt
Krzysztof Halasa wrote:
> Udo van den Heuvel <[EMAIL PROTECTED]> writes:
>
>> At the bottom I added a dmesg output of the kernel after boot.
>> I more or less know that irq 20 for the DVB-S card (saa7146 (1)) is
>> 'working'. I know that irq 16 for saa7146 (0) (DVB-T) is not working for
>> i2c alt
Udo van den Heuvel <[EMAIL PROTECTED]> writes:
> At the bottom I added a dmesg output of the kernel after boot.
> I more or less know that irq 20 for the DVB-S card (saa7146 (1)) is
> 'working'. I know that irq 16 for saa7146 (0) (DVB-T) is not working for
> i2c although the card does work perfect
[EMAIL PROTECTED] (Lennart Sorensen) writes:
> The PCI spec doesn't require 4 seperate interrupts. They certainly can
> all be the same. I do believe it does require the rotation method on
> anything using PCI bridges
Correct, PCI-PCI bridges have to rotate their INT lines (used ones
only, of c
On Mon, Feb 19, 2007 at 04:43:55PM +0100, Udo van den Heuvel wrote:
> Lennart Sorensen wrote:
> > On Mon, Feb 19, 2007 at 05:04:48AM +0100, Udo van den Heuvel wrote:
> >> lspci and interrupts at the bottom. yes, we have apic.
> >
> > Well you could always try to just change the setting
>
> You me
Lennart Sorensen wrote:
> On Mon, Feb 19, 2007 at 05:04:48AM +0100, Udo van den Heuvel wrote:
>> lspci and interrupts at the bottom. yes, we have apic.
>
> Well you could always try to just change the setting
You mean the Device Number of the riser card?
Or?
> to see if you find
> one where the
On Mon, Feb 19, 2007 at 05:04:48AM +0100, Udo van den Heuvel wrote:
> lspci and interrupts at the bottom. yes, we have apic.
Well you could always try to just change the setting to see if you find
one where the interrupts are happy. If you change the setting by one at
a time, you should only have
Lennart Sorensen wrote:
>> So IRQ 16 and 20. But when using the stock 2.6.20 kernel there is no
>> communication with the DVB-T card (the frontend), so there is no
>> /dev/dvb/* entry. This points to an IRQ problem.
>
> Any documentation on that riser card?
>
> I guess it is possible the card doe
On Sun, Feb 18, 2007 at 09:42:26PM +0100, Krzysztof Halasa wrote:
> [EMAIL PROTECTED] (Lennart Sorensen) writes:
>
> > My understanding (which is better of verified against the specs) is:
> >
> > PCI interrupts (PCI INTA to INTD) are rotated for every slot by one. So
> > slot 0, 4, 8, etc see INTA
Lennart Sorensen wrote:
> On Sun, Feb 18, 2007 at 05:15:30PM +0100, Udo van den Heuvel wrote:
>> FYI: My situation is a VIA Epia EN12000 with a TranquilPC dual PCI riser
>> where only the Device Number can be changed.
>> The kernel sees the two DVB cards in there as:
>>
>> saa7146: register extensi
On Sunday 18 February 2007 19:39, Lennart Sorensen wrote:
[snip]
> > > On a PC, the BIOS is supposed to assign interrupts to devices based on
> > > those rules, since that is how the hardware must be done according to
> > > the PCI specifications.
> >
> > I set the BIOS for 'PnP OS installed'. Shou
Udo van den Heuvel <[EMAIL PROTECTED]> writes:
> FYI: My situation is a VIA Epia EN12000 with a TranquilPC dual PCI riser
> where only the Device Number can be changed.
With jumpers?
> So IRQ 16 and 20. But when using the stock 2.6.20 kernel there is no
> communication with the DVB-T card (the f
[EMAIL PROTECTED] (Lennart Sorensen) writes:
> My understanding (which is better of verified against the specs) is:
>
> PCI interrupts (PCI INTA to INTD) are rotated for every slot by one. So
> slot 0, 4, 8, etc see INTA->realINTA, INTB->realINTB. INTC->realINTC,
> INTD->realINTD
> slot 1, 5, 9, e
On Sun, Feb 18, 2007 at 05:15:30PM +0100, Udo van den Heuvel wrote:
> FYI: My situation is a VIA Epia EN12000 with a TranquilPC dual PCI riser
> where only the Device Number can be changed.
> The kernel sees the two DVB cards in there as:
>
> saa7146: register extension 'budget_av'.
> ACPI: PCI In
Lennart Sorensen wrote:
> On Sun, Feb 18, 2007 at 03:07:29PM +0100, Udo van den Heuvel wrote:
>> How, based on what information, does Linux assign an IRQ to each card,
>> plugged into the riser?
>> How can one tweak/influence the irq routing?
>> How can I make a dual riser card work so that both ca
On Sun, Feb 18, 2007 at 03:07:29PM +0100, Udo van den Heuvel wrote:
> Is there some howto information available about using PCI riser cards
> (with multiple PCI slots) under Linux?
> Several incarnations exist of PCI riser cards with two PCI slots where
> the Device Number of one slot can be change
Hello,
Is there some howto information available about using PCI riser cards
(with multiple PCI slots) under Linux?
Several incarnations exist of PCI riser cards with two PCI slots where
the Device Number of one slot can be changed.
How, based on what information, does Linux assign an IRQ to each
"Jhon H. Caicedo O." wrote:
> This is an updated version of the patch for AMD756 PCI IRQ Routing,
> the changes are to use the read/write_config_nybble functions,
> this makes the code shorter.
Looks much better, thanks!
> + printk(KERN_INFO "AMD756: dev %04x
Hi,
Thanks for your comment,
I haven't used read_config_nybble, write_config_nybble in order to use the
same code with this kernel patch (2.4.X) and a patch for pcmcia-cs
(pci_fixup.c) to use with linux 2.2.X
I think it would be better to rewrite the patch using the nybble functions
and "impor
Can you use read_config_nybble and write_config_nybble, in your patch?
--
Jeff Garzik | Andre the Giant has a posse.
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo in
Hi,
I have been working on a small patch to add support for AMD756 PCI IRQ
Routing with linux-2.4.5
This has been tested with a Gigabyte 7IXE 7F board and several PCI cards,
including a SMC-Lucent PCI Cardbus Bridge which doesn't get an IRQ
assigned by the BIOS.
If anybody has a board
(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
...
...
> in fact vanilla 2.4.0 did believe what the bios states,
> namely the broken
> routing table. It didn't believe however what the devices config space
> reports - which turned out to be correct.
The PIRQ (PCI IRQ Routing table) is a Windows 95/98 convention
(requirement). I
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
. i've been told a few times that it's a problem with pci irq
routing, but have been able to find a fix. reports of this problem pop
up every-so-often on the linux-usb list.
here's my dump_pirq output:
Interrupt routing table found at address 0xfdb50:
Version 1.0, size 0x0
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
in which case
we pretty much _know_ that we do the right thing already.
(And _please_ don't make the subject line anything fancy. I want that
subject line to be "dump_pirq" and nothing else, ok?)
Linus
#!/usr/bin/perl
#
# dump_pirq 1.20 2000/12/19 19:19:52
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
Hi,
following happened on my well-known SMP VIA based GA6VXD7 motherboard.
Last week on Thursday I decided to connect printer to the box. To do that
I had to switch parallel port mode from ECP to Normal (because of I
had problems with that printer). Today I found, that since that time
(Thu 3:57
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 the
when i don'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
eves 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 for help.)
i have an ethernet card on
On Fri, 15 Dec 2000, Linus Torvalds wrote:
> I'm surprised: "yenta_init()" will re-initialize the yenta
> PCI_BASE_ADDRESS_0 register, but maybe there's something wrong there. Try
right - but it is just writing back the bogus 0xe6000 thing.
> adding a pci_enable_device() to turn the device on a
On Fri, 15 Dec 2000, Martin Diehl wrote:
>
> 3) The TI1131 is apparently not PCI PM 1.0 compliant. At least it seems it
> has been replaced by the 12xx series at the moment some major player
> required PCI PM 1.0 to get his "Designed for ..." label in '98 ;-)
> So I had to add some code to save
On Thu, 7 Dec 2000, Linus Torvalds wrote:
> Ok, definitely needs some more work. Thanks for testing - I have no
> hardware where this is needed.
Well, so I've tried to go on since my box has this "feature". Seems I
finally got the thing tracked down to several issues with mutual influence
and th
>The problem seems to be the "pci_get_interrupt_pin()" call. We should not
>do that. The pirq table has the unmodified device information - and when
>we try to swizzle the pins and find the bridge that the device is behind,
>we're trying to be way too clever.
Both with/without the change you men
Martin,
I finally got access to a machine that truly has multiple PCI buses and
bridges in between them, and at least for that machine the x86 IRQ lookup
does not work at all.
The problem seems to be the "pci_get_interrupt_pin()" call. We should not
do that. The pirq table has the unmodified d
On Thu, 7 Dec 2000, Linus Torvalds wrote:
> > btw, I'm thinking I could guess the routing from the VLSI config space,
> > but I don't have any doc's. Would it be worth to try to add some specific
>
> Please do. You might leave them commented out right now, but this is
Ok. Apparently it's the "p
On Thu, 7 Dec 2000, Linus Torvalds wrote:
> > btw, I'm thinking I could guess the routing from the VLSI config space,
>
> Please do. You might leave them commented out right now, but this is
> actually how most of the pirq router entries have been created: by looking
> at various pirq tables and
On Thu, 7 Dec 2000, Martin Diehl wrote:
>
> btw, I'm thinking I could guess the routing from the VLSI config space,
> but I don't have any doc's. Would it be worth to try to add some specific
> get/set methods for this device? What about testers (or people who have
> access to the docs)?
Pleas
On Wed, 6 Dec 2000, Linus Torvalds wrote:
> On Wed, 6 Dec 2000, Martin Diehl wrote:
> >
> [Cardbus config space lost after APM suspend/resume]
>
> Can you remind me in a day or two if I haven't gotten back to you? I don't
> have any machines that need this, but I've seen ones that do, and if
>
On Wed, 6 Dec 2000, Martin Diehl wrote:
>
> problems with recent 2.4.0-test1* on my HP OmniBook 800 are probably
> combined PCMCIA(CB) / PCI / APM issues. The point is my 16bit cards
> (modem+ne2k) are working perfectly fine with yenta sockets until the first
> suspend/resume. Afterwards the PC
On Tue, 5 Dec 2000, Linus Torvalds wrote:
> Anybody else who has had problems with PCI interrupt routing (tends to be
> "new" devices like CardBus, ACPI, USB etc), can you verify that this
> either fixes things or at least doesn't break a setup that had started
> working earlier..
problems with
On Tue, 5 Dec 2000, Linus Torvalds wrote:
> WHY this happens is unclear, but it could be several reasons:
> - undocumented "Plug'n'Play OS true behaviour"
> - BIOS bugs. 'nuff said.
> - warm-booting from an OS that _does_ set the interrupt routing,
>and also sets the PCI config space thing
1 - 100 of 101 matches
Mail list logo
