PCI IRQ Routing table - forcing values

PCI IRQ Routing table - forcing values

Post by Mr-T » Thu, 26 Jun 2003 10:50:13



Greetings,

I have an older TI Extensa 900CDT laptop (Pentium 133, 32Mb of RAM) which
suits my needs fine, but the onboard TI PCI1130 CardBus controller does
not work with cardbus cards. After a year of trying, I just could not get
a USB 2.0 CardBus card I have to work, despite having the knowledge that
Windows 98 would route the CB controller to IRQ 10.

As such, I tried specifying pci=irqmask=0x0400 (actually, IRQ 9,10 and 11
are valid PCI IRQs, all were tested to no avail) which actually assigned
IRQ 10 to the CB controller and subsequently the USB 2.0 CardBus card.
However, this was not enough and the USB still wouldn't work (the IRQ
assignment was probably bogus).

I had given up on this until I recently found a program called "DOS Point
Enabler for USB 2.0 CardBus Adapter" (http://www.tssc.de/index.htm) which
allows USB storage devices to be used on DOS. This initially didn't work,
despite instructing the utility to use IRQ10.

This is where it gets interesting: There's a command line param for this
DOS program called "Force updating of PCI IRQ routing table for socket
(even if selected IRQ is already in table)". After specifying that option,
the program did just that and the USB 2.0 HDD works fine in DOS on IRQ10.

Is it in any way possible for me to force the IRQ table's values as this
DOS program does? I'd basically like to route the Cardbus controllers
(0:04.0 and 0:04.1 to IRQ 10) via the IRQ routing table, but have no idea
how to do this. If it is possible, what code should I modify? Anyone have
experience with this?

The IRQ controller is recognised by dump_pirq (from pcmcia-cs):
--
Interrupt routing table found at address 0xf6940:
  Version 1.0, size 0x0060
  Interrupt router is device ff:1f.7
  PCI exclusive interrupt mask: 0x0000 []

Device 00:03.0 (slot 1):
  INTA: link 0x02, irq mask 0x0400 [10]
  INTB: link 0x03, irq mask 0x0400 [10]
  INTC: link 0x04, irq mask 0x0400 [10]
  INTD: link 0x01, irq mask 0x0400 [10]

Device 00:04.0 (slot 2):
  INTA: link 0x01, irq mask 0x0e00 [9,10,11]
  INTB: link 0x04, irq mask 0x0e00 [9,10,11]

Device 00:02.0 (slot 0):

Device 00:06.0 (slot 0):

Interrupt router at ff:1f.7:
Could not read router info from /proc/bus/pci/ff/1f.7.
--

lspci output:
--
00:00.0 Host bridge: Acer Laboratories Inc. [ALi] M1521 [Aladdin III] (rev
1c)
00:02.0 ISA bridge: Acer Laboratories Inc. [ALi] M1523 (rev 07)
00:04.0 CardBus bridge: Texas Instruments PCI1130 (rev 04)
00:04.1 CardBus bridge: Texas Instruments PCI1130 (rev 04)
00:06.0 VGA compatible controller: Chips and Technologies F65550 (rev c6)
00:07.0 IDE interface: CMD Technology Inc PCI0643
--

Any help would be most appreciated.

Thanks,
Jonathan

 
 
 

PCI IRQ Routing table - forcing values

Post by Mr-T » Thu, 26 Jun 2003 14:06:48


I can't be far off with getting this to work properly after testing the
following:

1. Start into DOS and run USBENAB with the parameters as before to force
updating of the PCI IRQ Routing Table.
2. Use loadin to load the Kernel and then start Linux from DOS.

This worked fine, assigning IRQ10 and actually working with all USB
devices that I tested - I didn't even have to specify pci=irqmask=0x0400
to use the parameter "pci=irqmask=0x0400".

I have a slight problem with this approach and that is USBENAB is a
shareware program that will expire in 14 days. I don't really need the DOS
support, but I'd really like to have this work properly on Linux.

Is there any way to do this?

 
 
 

PCI IRQ Routing table - forcing values

Post by Peter Christ » Thu, 26 Jun 2003 19:27:36


I don't know if this is a similar problem or not, but.......

When I got my new laptop 18 months back, I had a lot of problems with sound not
working under Linux. I eventually traced it to an irq problem, but couldn't
see how to fix it. It appeared that the irq look-up table in the bios was
corrupt (or just plain wrong!). The reason it worked under windoze was because
windoze recognized it as an ACPI system, and ACPI will take over irq routing
from the bios.

The solution was to apply a recent acpi patch (from sourceforge) to the kernel,
and activate acpi rather than apm. This provided an instant cure for all my
irq problems. I still have to apply a patch even with 2.4.21 (!) to get sound
to work..

Of course, this is only relevant if you have an ACPI enabled machine, but it
might be worth investigating....

Good Luck!

--
Pete

(make the obvious amendments to reply!)

 
 
 

PCI IRQ Routing table - forcing values

Post by Mr-T » Thu, 26 Jun 2003 20:55:08


Hi Pete,

I agree, ACPI is certainly the way to go with newer laptops, but this one
is about 5 years old now, so most likely, it won't be ACPI compliant.

I do recall that when I had Windows installed on this computer at one
stage, there was mention of ACPI in the device manager, but I don't think
that this is necessarily referring to assignment of resources (although I
do find it a little strange).

Do you (or anyone else reading this) know of a way to check (other than
recompiling the Kernel) to see if this notebook has ACPI?

 
 
 

PCI IRQ Routing table - forcing values

Post by lobotom » Fri, 27 Jun 2003 07:06:59



> Hi Pete,

> I agree, ACPI is certainly the way to go with newer laptops, but this
> one is about 5 years old now, so most likely, it won't be ACPI
> compliant.

> I do recall that when I had Windows installed on this computer at one
> stage, there was mention of ACPI in the device manager, but I don't
> think that this is necessarily referring to assignment of resources
> (although I do find it a little strange).

> Do you (or anyone else reading this) know of a way to check (other than
> recompiling the Kernel) to see if this notebook has ACPI?

The ACPI controller should appear as a PCI device, if it exists.  You
should see a device listing from lspci for it.  For instance on my desktop
(even though ACPI is not enabled) I see this:

00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)

Also there may be some settings related to it in the BIOS, although a lack
thereof does not mean that it doesn't support ACPI.  I'd also be skeptical
of a 5-year old machine supporting ACPI, although it actually has been
around for a while, if not supported decently under Linux -- I know that
some Pentium-era hardware I have used supported it.

--
Not to have been a dupe, that will have been my best possesion, my best
deed, to have been a dupe, wishing I wasn't, thinking I wasn't, knowing
I was, not being a dupe of not being a dupe.  
--Samuel Beckett, The Unnamable

 
 
 

PCI IRQ Routing table - forcing values

Post by David Goodenoug » Fri, 27 Jun 2003 16:45:51




>> Hi Pete,

>> I agree, ACPI is certainly the way to go with newer laptops, but this
>> one is about 5 years old now, so most likely, it won't be ACPI
>> compliant.

>> I do recall that when I had Windows installed on this computer at one
>> stage, there was mention of ACPI in the device manager, but I don't
>> think that this is necessarily referring to assignment of resources
>> (although I do find it a little strange).

>> Do you (or anyone else reading this) know of a way to check (other than
>> recompiling the Kernel) to see if this notebook has ACPI?

> The ACPI controller should appear as a PCI device, if it exists.  You
> should see a device listing from lspci for it.  For instance on my desktop
> (even though ACPI is not enabled) I see this:

> 00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)

I have several laptops which all use ACPI, and none of them have the ACPI
controller as a PCI device.  They are mainly SIS chip boxes, but I know
ACPI works on them (in fact some of them have no APM) as the support is
loaded and used to shutdown the machine.

David

- Show quoted text -

Quote:

> Also there may be some settings related to it in the BIOS, although a lack
> thereof does not mean that it doesn't support ACPI.  I'd also be skeptical
> of a 5-year old machine supporting ACPI, although it actually has been
> around for a while, if not supported decently under Linux -- I know that
> some Pentium-era hardware I have used supported it.

 
 
 

PCI IRQ Routing table - forcing values

Post by Mr-T » Sat, 28 Jun 2003 22:02:45


Thanks for the suggestion, but it hasn't solved the problem. The kernel
reported that there were invalid ACPI PCI IRQ routing tables and other
messages indicated that ACPI wasn't present.

I guess I'll have to keep trying or just buy a new notebook.

Quote:> > Also there may be some settings related to it in the BIOS, although a
> > lack thereof does not mean that it doesn't support ACPI.  I'd also be
> > skeptical of a 5-year old machine supporting ACPI, although it
> > actually has been around for a while, if not supported decently under
> > Linux -- I know that some Pentium-era hardware I have used supported
> > it.

 
 
 

1. How Do Routing Table Entries Get Added to Routing Table at Bootup?

I have, what I think, is a simple question for the TCP/IP guys out there
who are familar with routing tables on AIX 4.1.5/4.2.1 in an IBM SP
environment. Or maybe not.

I have recently noticed that when I execute a 'netstat -r' on a
particular node in the SP environment, there are routing table entries
that I know I didn't put in there. I have to delete these "unwelcomed"
entries and re-add the correct ones. This is undesireable and maybe a
quick crash course in routing tables is justified. These unwelcomed
routing table entries seem to be automatically added right after I have
IPL'ed the node in question.

How did these routing table entries get added in the routing table? Does
anybody know the process?

Thank you in advance for your responses.

  vcard.vcf
< 1K Download

2. New user, need help?

3. Force a flag 'G' in routing table ?

4. Ping fails on PPP

5. forcing irq for a particular pci device

6. dbx under solaris 7 seg faults

7. Forcing PCI-slot IRQ Settings !@#$%

8. HPFS with Linux?

9. Does anything look wrong with this that would case IRQ conflicts/routing table errors?

10. AMD756VIPER PCI IRQ Routing Patch (Need Additional Tests)

11. Problems with PCI IRQ routing

12. yenta_socket driver PCI irq routing fix

13. Cyrix PCI IRQ routing fix