[Mit]

Could the port being set to uplink cause the drop to half duplex?

Possibly, wouldn't have thought so thou.

If it wasn't the port, what else could it have been (the hub supports full duplex)?

The drivers / kernel on the machine, the hardware? Is the machine running for some reason in 10Mbit/s mode, instead of 100Mbit/s - would cause a bit of a drop off on speed if a few users are accessing it.

What exactly ARE these errors? I'm guessing the first example is something to do with the IRQ, but I have no idea about the others.

Googling around, seemed to suggest an error in the kernel / network card module's code. Suggesting a recompile of the kernel to a newer version was the main fix. Its not something i've noticed, and i've got 2 Linux machines here, both with RTL8139 network cards. (had to change one for 3com now, i managed to somehow blow the card up of the work machine \o/)

Why, given that the hub in question has since been disconnected (days ago, in fact) and all the clients have been restarted several times (and so renewed their DHCP leases), did the machine not bring the connection back up to full duplex mode?

Cos it requires THE machine to restart the network to change from Half to Full duplex.

Is there any way other than a restart of the machine (which I've just done) to fix the problem if it happens again?

/etc/rc.d/net.eth0 restart
or
/etc/init.d/net.eth0 restart

or similar, basically, restart the network using the init scripts.

From: "X"
> After I started to use RTL8139 in 100 Mbit mode I started to get this
> under heavy traffic:


AFAICS, you can ignore these messages:


> eth3: RTL8139 Interrupt line blocked, status 4.
> eth3: RTL8139 Interrupt line blocked, status 4.


The driver uses a timer to recover from hung transceivers. The timer noticed
that the card has new packets pending, but that the interrupt is not (yet)
called. How many of these messages do you receive, and how many interrupt
arrive? (cat /proc/interrupts). It's possible that they are caused by the
latency between "hardware triggers the interrupt" and "driver has
acknowledged the interrupt"


> eth3: SMP simultaneous entry of an interrupt handler.
rtl8129() is running on both cpus: [i guess because]
* one cpu because the hardware interrupt arrived
* one cpu because the timer called the function.

I guess that "dev->interrupt" enforces the synchronization, but I don't
understand why "dev->interrupt" is reset to 0:
rtl8129_interrupt():
> [...]
> /* A lock to prevent simultaneous entry bug on Intel SMP machines.
*/
> if (test_and_set_bit(0, (void*)&dev->interrupt)) {
> printk(KERN_ERR"%s: SMP simultaneous entry of an interrupt
handler.\n",
> dev->name);
> dev->interrupt = 0; /* Avoid halting machine. */
> return;
> }

Taken from http://web.gnu.walfield.org/mail-arc...uary/2181.html

might help explain whats going on...