On 11-Aug-98 Ramin Sina wrote:

Hi Ted. Thanks for your reply. ifconfig and resolv.conf seem to be normal and ping localhost works. The first thing I thought was to reboot. Also I now have noticed that telnet from outside DOES work, except it takes 5 minutes to get connected. ftp times out. Probably the same thing is true in reverse direction. Something must have happened to make connections very slow. There seems to be no problem with networking on other machines on the same network.

If it DOES work but takes ages to kick in then my immediate thought is an IRQ conflict. Do you have any other device on the same IRQ as the ethernet card? (I sincerely hope you don't have anything else at the same base-address!). Best of luck, as always. Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) Date: 11-Aug-98 Time: 13:59:17 -------------------------------------------------------------------- - To get out of this list, please send email to majordomo@suse.com with this text in its body: unsubscribe suse-linux-e

On 11-Aug-98 Ramin Sina wrote:

Hi Ted and thanks again for your message. For some miraculous reason the networking is back to the speed. I must confess I don't know what IRQ is, but I have had asked our school administer to turn on a second line for oyr ethernet jack for another computer that we are supposed to get. Maybe there was a mess up there. Every thing is fine now, atleast at the moment. Thanks again.

Hi again. From what you say it might well be an IRQ problem, since the second line might have triggered it. Short lesson on IRQ ("Interrupt ReQuest"). Any device that needs attention from the CPU and can't afford to wait sends an IRQ. There is a bunch of circuit lines on the board called IRQ lines. On the PC there are 16 of them. Each device has an IRQ, from 0 to 15, and a "base address". When it wants attention, it places a voltage on the appropriate IRQ line. These lines are monitored by the CPU, and when one of them changes the CPU switches to "servicing" the interrupt (actually, this is oversimplified: there are "maskable" interrupts which can be kept waiting if something more urgent is being done, and "non-maskable" interrupts which go straight through whatever else is happening. Pressing the resert button, for instance, generates an NMI). When the CPU knows which IRQ line it is getting the interrupt from, it then looks up the corresponding device base address which is a memory address which can be used for sending signals to the device. It is possible for two devices to share the same IRQ (but have different addresses). The classic cases are the standard 4 serial ports (COM1, COM2, COM3 and COM4 in DOS, /dev/ttyS0-3 in Linux). By default, these are on COM1: IRQ4, 03F8h; COM2: IRQ3, 02F8h; COM3: IRQ4, 03E8h; COM4: IRQ3, 02E8h DOS and Windows use a "polling driver": when, say, IRQ4 is detected, the driver cycles round addresses 03F8h and 03E8h looking for whichever responds appropriately. This is slow but it resolvs the conflict. Linux drivers typically do not "poll" and so tend to get locked onto one of the possible devices (e.g. if your mouse is on COM1 and you modem on COM2 then mouse activity may block Linux from looking at the modem); however, when one of the devices lets up in its demands then the other has a chance to get through. Therefore, a typical symptom of an IRQ conflict is that a device EVENTUALLY works, but this may take a few minutes, and it is likely to be slow and halting when it does work. Clearly, if you have both devices on the same IRQ AND on the same address, there will be total confusion. Now ethernet cards have IRQs and addresses too: for instance, my NE2000 clones typically work on IRQ11 at address 0x300h. Until you start sticking cards in, usually IRQs 2, 10, 11,12 and 15 are likely to be free. So if you put in two ethernet cards, and by chance they have the same IRQ, you may expect one of them to lock out the other for extended periods of time. You set IRQ and base address either by jumpers on the card's circuit board or by software commands. I hope this helps. Best wishes, Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) Date: 11-Aug-98 Time: 18:26:27 -------------------------------------------------------------------- - To get out of this list, please send email to majordomo@suse.com with this text in its body: unsubscribe suse-linux-e

Ted, Don't appologize! I kind of liked that explanation. I'm sure others did as well. Nicely done. Steve (Ted Harding) wrote:

On 11-Aug-98 Ted Harding wrote:

...

On 11-Aug-98 Ramin Sina wrote:

...

Thanks again.

Hi again. From what you say it might well be an IRQ problem, since the second line might have triggered it.

Short lesson on IRQ ("Interrupt ReQuest"). Any device that needs attention

Sorry everybody! That was meant to be a private mail, not a soapbox public lecture on IRQs etc!

Mea culpa. Ted.

-------------------------------------------------------------------- E-Mail: (Ted Harding) Date: 11-Aug-98 Time: 21:07:34 -------------------------------------------------------------------- - To get out of this list, please send email to majordomo@suse.com with this text in its body: unsubscribe suse-linux-e

- To get out of this list, please send email to majordomo@suse.com with this text in its body: unsubscribe suse-linux-e