Probably because the ethernet driver or hardware has a bug, and the rx buffer is full, and it has been configured to enable pause.
I once took down an entire corp. net by doing serial kernel debugging on a machine with pause frames enabled. Once the debugger took control of the kernel, the driver's rx interrupt handler stopped running, and the rx buffers filled. Eventually, the rx buffers were totally consumed, and the NIC started to send pause frames rather than dropping the packets. To make matters worse, I was remote, so I had to call somebody to powercycle the box.
I wonder if it is an issue with the kernel not keeping up, or if it is due to some other odd hardware effect (sometimes "gigabit" nics on embedded boards are really connected to a USB2.0 bus, which is slower than gigabit).
Probably because the ethernet driver or hardware has a bug, and the rx buffer is full, and it has been configured to enable pause.
I once took down an entire corp. net by doing serial kernel debugging on a machine with pause frames enabled. Once the debugger took control of the kernel, the driver's rx interrupt handler stopped running, and the rx buffers filled. Eventually, the rx buffers were totally consumed, and the NIC started to send pause frames rather than dropping the packets. To make matters worse, I was remote, so I had to call somebody to powercycle the box.
For extra points use an ip phone system that's on the same network as your computers.
Looks like it is enabled by default (for at least some NICs) in linux when the receive buffer is too full.
https://www.kernel.org/doc/Documentation/networking/ixgbe.tx...
I wonder if it is an issue with the kernel not keeping up, or if it is due to some other odd hardware effect (sometimes "gigabit" nics on embedded boards are really connected to a USB2.0 bus, which is slower than gigabit).
It's not necessarily wrong, is it? I mean the TV could legitimately have a full ethernet buffer, and the switch should handle that appropriately.