|
Home > Archive > alt.os.linux > June 2002 > how to resolve IRQ conflict in Linux?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
how to resolve IRQ conflict in Linux?
|
|
| gilgamesh 2002-06-24, 7:11 pm |
| I have two 3Com 3c509 ISA NIC's working fine in my HP Pentium 233mhz box
running Redhat 7.2, but want to add a third. The problem is an IRQ
conflict:
eth0 Link encap:Ethernet HWaddr 00:60:97:12 5:F5
inet addr:10.0.0.40 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:377 errors:0 dropped:0 overruns:0 frame:0
TX packets:246 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:28546 (27.8 Kb) TX bytes:23986 (23.4 Kb)
Interrupt:5 Base address:0x220
eth1 Link encap:Ethernet HWaddr 00:A0:24:00:8B:A9
inet addr:64.175.234.106 Bcast:64.175.234.110
Mask:255.255.255.248
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:131 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:14479 (14.1 Kb) TX bytes:168 (168.0 b)
Interrupt:10 Base address:0x230
The above two NICs work fine. The one below has an IRQ conflict with eth1:
eth2 Link encap:Ethernet HWaddr 00:60:97:1E:9DB
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:10 Base address:0x300
root# dmesg | grep eth
eth0: 3c5x9 at 0x220, 10baseT port, address 00 60 97 12 d5 f5, IRQ 5.
eth1: 3c5x9 at 0x230, 10baseT port, address 00 a0 24 00 8b a9, IRQ 10.
eth2: 3c5x9 at 0x300, 10baseT port, address 00 60 97 1e 9d db, IRQ 10.
eth0: Setting Rx mode to 1 addresses.
eth1: Setting Rx mode to 0 addresses.
eth1: Setting Rx mode to 1 addresses.
root# cat /proc/interrupts
CPU0
0: 77005 XT-PIC timer
1: 3 XT-PIC keyboard
2: 0 XT-PIC cascade
5: 184 XT-PIC eth0
8: 1 XT-PIC rtc
10: 30 XT-PIC eth1
14: 5061 XT-PIC ide0
15: 0 XT-PIC ide1
NMI: 0
ERR: 0
root#
I've tried the usual, but with no luck:
root# vi /etc/modules.conf
alias parport_lowlevel parport_pc
alias eth0 3c509
alias eth1 3c509
alias eth2 3c509
options eth2 irq=11 <-----this did not work
I also tried with different syntax:
root# vi /etc/modules.conf
alias parport_lowlevel parport_pc
alias eth0 3c509
alias eth1 3c509
alias eth2 3c509
options eth2 -o 3c501-1,io=0x300,irq=11 <-----this also did not work
I'm at the point of swapping out the NIC and trying some other NIC thinking
that the IRQ is hard coded on the card. I would think that one should be
able to change the IRQ assignments. At this point all I can say is IA
hardware is crap. Why did I ever leave Sun?
| |
| Bill Marcum 2002-06-24, 7:11 pm |
| On Tue, 18 Jun 2002 22:20:09 GMT,
>
>The above two NICs work fine. The one below has an IRQ conflict with eth1:
>
>eth2 Link encap:Ethernet HWaddr 00:60:97:1E:9DB
> BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
> Interrupt:10 Base address:0x300
>
Are you sure this is a problem? In the days of ISA cards, every I/O
device needed its own IRQ, but PCI cards can share IRQs.
If all three cards are connected and configured, can you ping other
machines on each network?
| |
| Ray Taylor 2002-06-24, 7:11 pm |
| On Tue, 18 Jun 2002 18:20:09 -0400, gilgamesh wrote:
> I have two 3Com 3c509 ISA NIC's working fine in my HP Pentium 233mhz box
> running Redhat 7.2, but want to add a third. The problem is an IRQ
> conflict:
<snip>
> I'm at the point of swapping out the NIC and trying some other NIC
> thinking that the IRQ is hard coded on the card. I would think that one
> should be able to change the IRQ assignments. At this point all I can
> say is IA hardware is crap. Why did I ever leave Sun?
ISA cards almost always have a setup utility you use to set the IRQ and
I/O address. The drivers are readily available from the 3Com web site,
and generally include that utility.
--
- Ray
- Disclaimer: This is my understanding. I have been wrong before. A lot.
- Remove _remove_ to reply by email.
| |
| gilgamesh 2002-06-24, 7:11 pm |
| Thanks for the tip.
I looked at 3com's site which pointed me to
http://www.scyld.com/network/updates.html - no mention of any utility for
Linux.
This was interesting, however:
Special instructions for Red Hat 7.0
Red Hat 7.0 has a flawed configuration with their default install. The
symptom is a variety of errors when trying to compile the driver update
source RPM. The easiest work-around is to use a precompiled RPM for Red Hat
7.0 running the x86 uniprocessor kernel from
ftp://ftp.scyld.com/pub/network/net...s-rh70.i386.rpm
Red Hat 7.0 uses the header files from an unreleased 2.3.99 kernel, rather
than installing the header files from the kernel that is actually running.
This was an attempt to make user-level binaries independent of the specific
kernel version, but it makes it impossible to automatically build kernel
modules.
A second problem is that 7.0 provides an experimental version of gcc that
was not intended for public release. The stable version of gcc needed to
correctly compile the kernel has been renamed to kgcc.
The work-around is to substitute kgcc for gcc and to
add -I/usr/src/linux/include on the compile command line when compiling by
hand. The Makefile in the tar file and RPM automatically include this
compile flag, however they cannot automatically use 'kgcc'.
To repeat: this is a flaw that was introduced with Red Hat 7.0. It is a Red
Hat configuration problem, not a driver update distribution bug. The symptom
of this bug is compile error messages such as
tulip.c: In function `tulip_open':tulip.c:1437: structure has no member
named `tbusy'tulip.c:1438: structure has no member named `start'
| |
| Peter T. Breuer 2002-06-24, 7:11 pm |
| gilgamesh <dave955@sbcglobal.net> wrote:
> I looked at 3com's site which pointed me to
> http://www.scyld.com/network/updates.html - no mention of any utility for
> Linux.
You're wrong. That page is ALL for linux. It's donald becker's page.
There you will find the utilities that set cards every which way.
> Special instructions for Red Hat 7.0
> Red Hat 7.0 has a flawed configuration with their default install. The
> symptom is a variety of errors when trying to compile the driver update
> source RPM. The easiest work-around is to use a precompiled RPM for Red Hat
> 7.0 running the x86 uniprocessor kernel from
> ftp://ftp.scyld.com/pub/network/net...s-rh70.i386.rpm
Well, he means that you should use the precompiled module in the rpm
rather than give yourself a headache.
> Red Hat 7.0 uses the header files from an unreleased 2.3.99 kernel, rather
> than installing the header files from the kernel that is actually running.
> This was an attempt to make user-level binaries independent of the specific
> kernel version, but it makes it impossible to automatically build kernel
> modules.
Uh .. all distros do nowadays. I agree with Don that this is silly. But
Linus and some other people want it that way. What it does is make _3rd
party_ modules pretty well damn near impossible to compile. I
distribute scripts that go hunting for the kernel directory with the
source and -I it in front of everything else. That copes, usueally.
> A second problem is that 7.0 provides an experimental version of gcc that
> was not intended for public release. The stable version of gcc needed to
> correctly compile the kernel has been renamed to kgcc.
Yadda yadda. We know. I agree. RH are still fixing it. It's 2.96.
> To repeat: this is a flaw that was introduced with Red Hat 7.0. It is a Red
> Hat configuration problem, not a driver update distribution bug. The symptom
> of this bug is compile error messages such as
You are taking this way too serious! The difficulties are trivia.
> tulip.c: In function `tulip_open':tulip.c:1437: structure has no member
> named `tbusy'tulip.c:1438: structure has no member named `start'
That's simply a headers issue. Compile with -I wherever up front.
Peter
| |
| gilgamesh 2002-06-24, 7:11 pm |
| well, it would not be the first time.... I'll check again. I've got a
whole box of those ISA 3c509's and I kept swapping out different cards until
I found one that came up as IRQ 12 (third try), so the immediate problem has
been solved. but I apprecaite the help.
"Peter T. Breuer" <ptb@oboe.it.uc3m.es> wrote in message
news:hk5pea.cmp.ln@news.it.uc3m.es...
> gilgamesh <dave955@sbcglobal.net> wrote:
> > I looked at 3com's site which pointed me to
> > http://www.scyld.com/network/updates.html - no mention of any utility
for
> > Linux.
>
> You're wrong. That page is ALL for linux. It's donald becker's page.
> There you will find the utilities that set cards every which way.
>
> > Special instructions for Red Hat 7.0
> > Red Hat 7.0 has a flawed configuration with their default install. The
> > symptom is a variety of errors when trying to compile the driver update
> > source RPM. The easiest work-around is to use a precompiled RPM for Red
Hat
> > 7.0 running the x86 uniprocessor kernel from
> > ftp://ftp.scyld.com/pub/network/net...s-rh70.i386.rpm
>
> Well, he means that you should use the precompiled module in the rpm
> rather than give yourself a headache.
>
> > Red Hat 7.0 uses the header files from an unreleased 2.3.99 kernel,
rather
> > than installing the header files from the kernel that is actually
running.
> > This was an attempt to make user-level binaries independent of the
specific
> > kernel version, but it makes it impossible to automatically build kernel
> > modules.
>
> Uh .. all distros do nowadays. I agree with Don that this is silly. But
> Linus and some other people want it that way. What it does is make _3rd
> party_ modules pretty well damn near impossible to compile. I
> distribute scripts that go hunting for the kernel directory with the
> source and -I it in front of everything else. That copes, usueally.
>
> > A second problem is that 7.0 provides an experimental version of gcc
that
> > was not intended for public release. The stable version of gcc needed to
> > correctly compile the kernel has been renamed to kgcc.
>
> Yadda yadda. We know. I agree. RH are still fixing it. It's 2.96.
>
> > To repeat: this is a flaw that was introduced with Red Hat 7.0. It is a
Red
> > Hat configuration problem, not a driver update distribution bug. The
symptom
> > of this bug is compile error messages such as
>
> You are taking this way too serious! The difficulties are trivia.
>
> > tulip.c: In function `tulip_open':tulip.c:1437: structure has no member
> > named `tbusy'tulip.c:1438: structure has no member named `start'
>
> That's simply a headers issue. Compile with -I wherever up front.
>
>
> Peter
| |
| Ray Taylor 2002-06-24, 7:12 pm |
| On Wed, 19 Jun 2002 03:30:34 -0400, gilgamesh wrote:
> well, it would not be the first time.... I'll check again. I've got a
> whole box of those ISA 3c509's and I kept swapping out different cards
> until I found one that came up as IRQ 12 (third try), so the immediate
> problem has been solved. but I apprecaite the help.
To use the 3Com utility, boot to a DOS boot disk (any version), insert the utility
diskette, etc etc.
--
- Ray
- Disclaimer: This is my understanding. I have been wrong before. A lot.
- Remove _remove_ to reply by email.
| |
|
| if it is a version B card it can also do PNP config.
I have one my self but it is a version A card so the dos boot and config is
for me.
You still need the config util to set it to PNP mode for isa.
"Ray Taylor" <skinner_remove_@myrealbox.com> wrote in message
news an.2002.06.20.06.37.02.173816.3770@myrealbox.com...
> On Wed, 19 Jun 2002 03:30:34 -0400, gilgamesh wrote:
>
> > well, it would not be the first time.... I'll check again. I've got a
> > whole box of those ISA 3c509's and I kept swapping out different cards
> > until I found one that came up as IRQ 12 (third try), so the immediate
> > problem has been solved. but I apprecaite the help.
>
> To use the 3Com utility, boot to a DOS boot disk (any version), insert the
utility
> diskette, etc etc.
>
>
> --
> - Ray
> - Disclaimer: This is my understanding. I have been wrong before. A lot.
> - Remove _remove_ to reply by email.
| |
| gilgamesh 2002-06-24, 7:13 pm |
| well, I found Donald Becker's Setup Utility at
http://www.scyld.com/diag/3c5x9setup.html (thanks Bill S.)
after compiling and running it, here's what I got:
root# ./3c5x9 -f -p 0x230 -P 0x230 -Q 13 -w -v
3c5x9setup.c:v1.00 6/19/2000 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
No interrupt sources are pending.
3c5x9 found at 0x230.
Indication enable is 00fe, interrupt enable is 009c.
Writing new transceiver/IO entry 0x0083.
Writing new checksum entry 0xbf6f.
EEPROM contents:
Model number 3c509 version 0, base I/O 0x230, IRQ 13, 10baseT port.
3Com Node Address 00:A0:24:04:17:EE (used as a unique ID only).
OEM Station address 00:A0:24:04:17:EE (used as the ethernet address).
Manufacture date (MM/DD/YY) 6/10/95, division 6, product CC.
Options: half duplex, enable linkbeat.
The computed checksum matches the stored checksum of bf6f.
funny thing is, when I checked the output of ifconfig, the IRQ did not
change to 13. so I went into the bios and disabled pnp and tried again.
still, no change. so I went back into the bios... no luck. it appears
that even though the card thinks it's IRQ 13, the bios is controlling
available IRQ's
| |
| green 2002-06-25, 12:25 am |
| does the driver even use IRQ's ?
ahh well as long as it works reliably who cares.
Good luck setting the rest up.
"gilgamesh" <dave955@sbcglobal.net> wrote in message
news:QAAR8.1441$cL6.68310176@newssvr14.news.prodigy.com...
> well, I found Donald Becker's Setup Utility at
> http://www.scyld.com/diag/3c5x9setup.html (thanks Bill S.)
>
>
>
> after compiling and running it, here's what I got:
>
>
>
> root# ./3c5x9 -f -p 0x230 -P 0x230 -Q 13 -w -v
>
> 3c5x9setup.c:v1.00 6/19/2000 Donald Becker (becker@scyld.com)
>
> http://www.scyld.com/diag/index.html
>
> No interrupt sources are pending.
>
> 3c5x9 found at 0x230.
>
> Indication enable is 00fe, interrupt enable is 009c.
>
> Writing new transceiver/IO entry 0x0083.
>
> Writing new checksum entry 0xbf6f.
>
> EEPROM contents:
>
> Model number 3c509 version 0, base I/O 0x230, IRQ 13, 10baseT port.
>
> 3Com Node Address 00:A0:24:04:17:EE (used as a unique ID only).
>
> OEM Station address 00:A0:24:04:17:EE (used as the ethernet address).
>
> Manufacture date (MM/DD/YY) 6/10/95, division 6, product CC.
>
> Options: half duplex, enable linkbeat.
>
> The computed checksum matches the stored checksum of bf6f.
>
>
>
>
>
> funny thing is, when I checked the output of ifconfig, the IRQ did not
> change to 13. so I went into the bios and disabled pnp and tried again.
> still, no change. so I went back into the bios... no luck. it appears
> that even though the card thinks it's IRQ 13, the bios is controlling
> available IRQ's
>
>
>
|
|
|
|
|