Very Computer

I'm having some strange issues with two ISA nics I have on a Mandrake
Linux box.  The Linux box has a combination of PCI and ISA nics that
are all recognized at boot time.  The PCI cards all seem to be working
properly, but the two ISA cards, though viewable under ifconfig, don't
seem to be able to route properly.  They both have the same routing
information as the PCI cards.  I'm able to ping the ISA cards assigned
IP from withing the box, but not externally.

I should also probably mention that the two ISA nics are old 10BaseT
SMC 8013s (actually, Western Digitals) that required manual jumper and
module (wd) configuration.  The first ISA card is set to io=0x280
irq=5 and the second is set to io=0x300 irq=13, which seemed to be
availiable (according to /proc).  Now here is one strange thing...
When I look at the io and irq info using ifconfig it reports the first
ISA card is on io=0x290 and the second is on io=0x310.  However, I
don't think this would account for the routing issue.

Any ideas as to what might cause this annomily?

Respectfully,

Gary

NOTE:  The two ISA cards are eth4 and eth5.

IFCONFIG:
eth4      Link encap:Ethernet  HWaddr 00:00:C0:E8:B9:82  
          inet addr:192.168.0.104  Bcast:192.168.0.255
Mask:255.255.255.255
          UP BROADCAST RUNNING 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:5 Base address:0x290 Memory:d0000-d4000

eth5      Link encap:Ethernet  HWaddr 00:00:C0:BE:1B:83  
          inet addr:192.168.0.105  Bcast:192.168.0.255
Mask:255.255.255.255
          UP BROADCAST RUNNING 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:13 Base address:0x310 Memory:cc000-d0000

ROUTING TABLE:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref  
Use Iface
192.168.0.40    *               255.255.255.255 UH    0      0      
0 eth4
192.168.0.10    *               255.255.255.255 UH    0      0      
0 eth1
192.168.0.30    *               255.255.255.255 UH    0      0      
0 eth0
192.168.0.1     *               255.255.255.255 UH    0      0      
0 eth3
192.168.0.50    *               255.255.255.255 UH    0      0      
0 eth5
192.168.0.20    *               255.255.255.255 UH    0      0      
0 eth2
127.0.0.0       *               255.0.0.0       U     0      0      
0 lo

|I should also probably mention that the two ISA nics are old 10BaseT
|SMC 8013s (actually, Western Digitals) that required manual jumper and
|module (wd) configuration.  The first ISA card is set to io=0x280
|irq=5 and the second is set to io=0x300 irq=13, which seemed to be
|availiable (according to /proc).  Now here is one strange thing...
|When I look at the io and irq info using ifconfig it reports the first
|ISA card is on io=0x290 and the second is on io=0x310.  However, I
|don't think this would account for the routing issue.

That's ok, it so happens that the 8013's controller's address is 0x10
higher than the address you pass it and that's what the driver is
reporting.

Did you remember to route those IRQs to the ISA bus in the BIOS setup?
Forgetting to do so would make the cards not get any interrrupts, hence
not receive packets.

You can always ping your own interface address, the network stack is
smart enough to loop the packets back regardless of whether the
interface can work on the wire.

For some reason I remember IRQ13 is used, for FPU interrupts maybe?
Maybe not on modern motherboards, but I'd check.

13 is for the FPU for sure. The IO address is fine but the IRQ
selection could be messing things up, it need another non-shared,
non-pci IRQ.

karl.

[...]

Quote:>I should also probably mention that the two ISA nics are old 10BaseT
>SMC 8013s (actually, Western Digitals) that required manual jumper and
>module (wd) configuration.  The first ISA card is set to io=0x280
>irq=5 and the second is set to io=0x300 irq=13, which seemed to be
>availiable (according to /proc).  

[...]

Most likely, neither IRQ 5 nor IRQ 13 is available on your system,
regardless of what /proc/interrupt shows you.

IRQ 5 is typically used by the soundcard, and IRQ 13 is not
available on any post-386 machine, as that's the interrupt
of the processor's FPU.

Michael
--

          Lumber Cartel Unit #456 (TINLC) & Official Netscum
    Note: If you want me to send you email, don't munge your address.

Unfortuntely, it doesn't seem to be an IRQ conflict or BIOS
misconfiguration.  After receiving several responses suggesting it
might be an IRQ conflict, I focused on this possibility.
Specifically, I decided to focus on eth5 that was formerly configured
with io=0x300 irq=13.  I decided to disable the LPT port (IRQ 7) in
the BIOS and assign its IRQ to eth5.  To test an make sure this new
IRQ would work, I rmmod the respective kernel module (wd) for eth5 and
then insmod the module, again, with options io=0x300 irq=7.  According
to ifconfig, the module seemed to take the new options fine.  I then
rebooted the machine (maintaining the new module options) and
configured the BIOS with the new IRQ for the ISA card.  I then
attempted to test the routing issue, again, to see if it had been
corrected.  Unfortuntely, the routing issue still persists.

I appreciate the excellent suggestions, but still wonder what the
problem might be.

Does anyone have any alternative theories or suggestions?

Respectfully,

Gary

Quote:>To test an make sure this new
>IRQ would work, I rmmod the respective kernel module (wd) for eth5 and
>then insmod the module, again, with options io=0x300 irq=7.  According
>to ifconfig, the module seemed to take the new options fine.  I then
>rebooted the machine (maintaining the new module options) and
>configured the BIOS with the new IRQ for the ISA card.  

[...]

So you had set the jumpers on the NIC to I/O 300 and IRQ 7, right?
And you did reserve that IRQ for ISA cards in your system's CMOS
settings?

Michael
--

          Lumber Cartel Unit #456 (TINLC) & Official Netscum
    Note: If you want me to send you email, don't munge your address.

It turns out that this particular issue was not one of conflicting
IRQs; it was that re-accuring problem of goober user error.

After taking a second peek at the jumper settings on the nic, it turns
out I had jumpered the nic to IRQ 10.  And when I pointed the driver
module for the nic to IRQ 10...Yes, you guessed it...It WORKED!

COMPUTER 1 | USER -1

Thanks, again, for all your help.

Respectfully,

Gary