[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Update ... Re: Ethernet newbee failure



>> First I want to thank everyone who sent me a reply, both private and on
>> the list. I now know 3 different way to create working routing tables.
>> With regret, this has not resolved the problem. It was John Hasler who
>> actually resolved things for me. I now have the following routing tables
>> on both machines:
>> 
>> Kernel IP routing table
>> Destination     Gateway         Genmask         Flags Metric Ref    Use
>> Iface
>> 127.0.0.0       *               255.0.0.0       U     0      0        1 lo
>> 10.0.0.0        *               255.0.0.0       U     0      0        0
>> eth0
>> 
>> 
>> I get better results now than ever before, but still can't complete a
>> ping.
>> 
>> Here are the facts:
>> 
>> 1. Each machine can ping itself successfully.
>> 
>> 2. A ping to the other machine returns 0 packets to the kernel.
>> 
>> 3. The PKT light on the hub blinks while a failed ping is in progress.
>> 
>> 
>> The NICs are EtherLink III cards connected through a hub using twisted
>> pair cable.
>> 
>> Suppositions:
>> 
>> Fact 1 is not useful, as the kernel, seeing the information in the routing
>> table, has no reason to go to the card to resolve the ping. In this
>> circumstance the kernel is talking to itself and the ping program, not the
>> card.
>> 
>> Fact 3 indicates that the ping is getting out of the kernel, into the
>> card, and onto the cable. When properly configured the card in machine one
>> gets a reply from the card in machine two, but fails to get that message
>> to the kernel. (fact 2)
>> 
>> At this point, it is my supposition that the card is responding on another
>> interrupt from the one it was commanded to use by isapnp, and the driver.
>> The kernel, the driver, and the isapnp program, all think the card has
>> been configured for base address 0300, and irq 10, yet no traffic makes it
>> out of the card into the kernel, suggesting that it is using another
>> interrupt.

 Isapnp? Turn off the pnp and try settings manually. 
 
>> As painful as it seemed at this point, I was ready to try loading the
>> driver commanding each interrupt that the card might use, hoping to
>> "stumble" on it by a careful search.
>> 
>> Although the documentation seems to indicate that the only parameter that
>> I can send to the driver is the irq, modconf says that the io base address
>> can also be entered. Worse than that, if you try to specify another
>> interrupt for the driver install, it hangs forever.
>> 
>> I was able to do an insmod including the parrameter, but the results were
>> not what I expected:
>> 
>> dwarf# insmod 3c509 irq=12
>> eth0: 3c509 at 0x300 tag 1, 10baseT port, address  00 10 5a de c8 16, IRQ
>> 10.
>> 3c509.c:1.16 2/3/98 becker@cesdis.gsfc.nasa.gov
>> 
>> 
>> Note that the driver still declares irq 10 rather than the irq 12 that I
>> requested. Is my syntax faulty?

 You propably have machines with ps/2 mouse and keyboards. The
 irq 12 is sort of reserved for these. If 10 is free, why not use it. One
 thing you might try is fiddling with the irq and settings with the dos 
 based 3c5x9cfg.exe program, that comes with the normal driver package
 from 3com (you can download this from www.3com.com). 
  
>> Ben Pfaff indicated that his card requires a special option before the
>> kernel can "hear" it. I can find no such indication for the EtherLink III
>> card, but his experience seems similar to mine. Can anyone clue me in?

 This is from Donald Becker's site (http://cesdis.gsfc.nasa.gov/linux/drivers/3c509.html) :

No received packets 
    If a 3c509, 3c562 or 3c589 can successfully transmit packets, but never receives packets (as reported by
    /proc/net/dev or 'ifconfig') you likely have an interrupt line problem. Check /proc/interrupts to verify that the
    card is actually generating interrupts. If the interrupt count is not increasing you likely have a physical conflict
    with two devices trying to use the same ISA IRQ line. The common conflict is with a sound card on IRQ10 or
    IRQ5. The easiest solution is to move the 3c509 to a different interrupt line. 

 And let's move this to -user, as it's the proper forum. 

	--j




Reply to: