Searched hist:160843 (Results 1 - 2 of 2) sorted by relevance
| /freebsd-10.2-release/sys/pci/ | ||
| H A D | if_rlreg.h | diff 160843 Sun Jul 30 23:25:21 MDT 2006 wpaul Fix the following bugs in re(4) - Correct the PCI ID for the 8169SC/8110SC in the device list (I added the macro for it to if_rlreg.h before, but forgot to use it.) - Remove the extra interrupt spinlock I added previously. After giving it some more thought, it's not really needed. - Work around a hardware bug in some versions of the 8169. When sending very small IP datagrams with checksum offload enabled, a conflict can occur between the TX autopadding feature and the hardware checksumming that can corrupt the outbound packet. This is the reason that checksum offload sometimes breaks NFS: if you're using NFS over UDP, and you're very unlucky, you might find yourself doing a fragmented NFS write where the last fragment is smaller than the minimum ethernet frame size (60 bytes). (It's rare, but if you keep NFS running long enough it'll happen.) If checksum offload is enabled, the chip will have to both autopad the fragment and calculate its checksum header. This confuses some revs of the 8169, causing the packet that appears on the wire to be corrupted. (The IP addresses and the checksum field are mangled.) This will cause the NFS write to fail. Unfortunately, when NFS retries, it sends the same write request over and over again, and it keeps failing, so NFS stays wedged. (A simple way to provoke the failure is to connect the failing system to a network with a known good machine and do "ping -s 1473 <badhost>" from the good system. The ping will fail.) Someone had previously worked around this using the heavy-handed approahch of just disabling checksum offload. The correct fix is to manually pad short frames where the TCP/IP stack has requested checksum offloading. This allows us to have checksum offload turned on by default but still let NFS work right. - Not a bug, but change the ID strings for devices with hardware rev 0x30000000 and 0x38000000 to both be 8168B/8111B. According to RealTek, they're both the same device, but 0x30000000 is an earlier silicon spin. |
| /freebsd-10.2-release/sys/dev/re/ | ||
| H A D | if_re.c | diff 160843 Sun Jul 30 23:25:21 MDT 2006 wpaul Fix the following bugs in re(4) - Correct the PCI ID for the 8169SC/8110SC in the device list (I added the macro for it to if_rlreg.h before, but forgot to use it.) - Remove the extra interrupt spinlock I added previously. After giving it some more thought, it's not really needed. - Work around a hardware bug in some versions of the 8169. When sending very small IP datagrams with checksum offload enabled, a conflict can occur between the TX autopadding feature and the hardware checksumming that can corrupt the outbound packet. This is the reason that checksum offload sometimes breaks NFS: if you're using NFS over UDP, and you're very unlucky, you might find yourself doing a fragmented NFS write where the last fragment is smaller than the minimum ethernet frame size (60 bytes). (It's rare, but if you keep NFS running long enough it'll happen.) If checksum offload is enabled, the chip will have to both autopad the fragment and calculate its checksum header. This confuses some revs of the 8169, causing the packet that appears on the wire to be corrupted. (The IP addresses and the checksum field are mangled.) This will cause the NFS write to fail. Unfortunately, when NFS retries, it sends the same write request over and over again, and it keeps failing, so NFS stays wedged. (A simple way to provoke the failure is to connect the failing system to a network with a known good machine and do "ping -s 1473 <badhost>" from the good system. The ping will fail.) Someone had previously worked around this using the heavy-handed approahch of just disabling checksum offload. The correct fix is to manually pad short frames where the TCP/IP stack has requested checksum offloading. This allows us to have checksum offload turned on by default but still let NFS work right. - Not a bug, but change the ID strings for devices with hardware rev 0x30000000 and 0x38000000 to both be 8168B/8111B. According to RealTek, they're both the same device, but 0x30000000 is an earlier silicon spin. |
Completed in 154 milliseconds