Bug 15384
| Summary: | e1000 needs checksum offloading blacklist entries | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Björn Jacke (bjoern) |
| Component: | Network | Assignee: | drivers_network (drivers_network) |
| Status: | RESOLVED WILL_NOT_FIX | ||
| Severity: | normal | CC: | alan, emil.s.tantilov, jbrandeb, tushar.n.dave |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.6 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
|
Description
Björn Jacke
2010-02-24 16:05:58 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=165676 shows more people with 82546EB controllers who see problems that may have the same cause. Maybe the whole 82546EB series needs to be blacklisted for checksum offloading. http://download.intel.com/design/network/specupdt/82546eb.pdf is the specification update for this part, and it doesn't mention anything about a checksum computation issue. I think I know of the patch that might need to be made to fix this issue in the kernel. 06:02.0 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
Subsystem: Intel Corporation PRO/1000 MT Dual Port Server Adapter
(numeric:)
06:02.0 0200: 8086:1079 (rev 03)
Subsystem: 8086:1179
is just another 82546GB bases card we have. It has the same checksumming bug.
This Intel document about the 82543GC shows that this is a known bug: ftp://download.intel.com/design/network/specupdt/82543gc.pdf 38. Transmit TCP Checksum Incorrectly Modified if Calculated as 0x0000 Problem: If the controller calculates a transmit TCP checksum as 0x0000, it will automatically change the checksum to 0xFFFF. Specifications call for 0xFFFF be substituted for 0x0000 for UDP packets to distinguish UDP packets that carry no checksum. However, the modification does not apply to TCP packets. Implication: If the receiving station is running MS-DOS and calculates a receive checksum of 0x0000, it will flag an error if the checksum contained in the packet is 0xFFFF. Other operating systems treat 0x0000 and 0xFFFF as equivalent in one’s complement math. UDP checksums are correct. Workaround: Intel modified the DOS Ethernet driver to check for a received checksum of 0xFFFF on a TCP/IP packet and change it back to 0x0000 before passing the packet to the operating system. Status: Intel does not plan to resolve this erratum in a future stepping of the 82543GC Gigabit Ethernet Controller. so far known to be broken are 82546EB, 82546GB and 82543GC. Is there a more complete list of broken cards available? Jesse: can someone @Intel tell which chipsets are affected? the TCP checksum offloading of those cards are still broken. The bug should not get resolved as "obsolete" but be the tcp checksum offloading be blacklisted instead. Here is the background info I found: Summary Because 0000h and FFFFh are equivalent in 1’s complement arithmetic, it will not cause problems if a checksum value of FFFFh is used instead of 0000h. Background For a UDP packet, a checksum value of 0000h means that the packet does not include a checksum. Thus, if the packet is supposed to include a checksum, and the checksum calculation happens to result in a value of 0000h, then the actual value used for the checksum field is FFFFh. The preferred method of verifying the IP, UDP or TCP checksum is to sum the covered data (in 16-bit quantities) using 1’s complement arithmetic and comparing the result to FFFFh. If it matches then the checksum is valid; otherwise it is invalid. This method is described in RFC 1071 (section 1, item 3) and in RFC 1624 (section 5). This allows the UDP checksum to be verified without the end system worrying about converting a checksum of 0000h into FFFFh. It also allows the IP and TCP checksum calculation to use this replacement. Because the values 0000h and FFFFh are equivalent in 1’s complement arithmetic, the sum will still be FFFFh for a valid checksum. In order to simplify the design, our hardware always converts a checksum value of 0000h into FFFFh. Because the RFC method accounts for this, there should be no conflict with well-written TCP/IP stacks. |