NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/34799: IP Filter does not work correctly with gem(4) when hardware chec

The following reply was made to PR kern/34799; it has been noted by GNATS.

From: "David H. Gutteridge" <>
Subject: Re: kern/34799: IP Filter does not work correctly with gem(4) when 
hardware chec
Date: Tue, 29 Jan 2008 21:55:50 -0500

 > > My guess is that revision 1 GMAC chips behave differently in this
 > > regard.
 >It could be.  The cards that I have are both rev. 0x01 and they exhibit
 >the problem, but they are Sun cards (one is ERI and one is GEM).  So, I
 >think that disabling HW receive checksums for Apple rev. 0 and for Sun
 >rev. 1 chips is the way to go.
 Oh, I thought only the Apple hardware was showing the problem.  It
 might be safer to assume then that none of the variations work
 properly.  The original report about the issue was from another macppc
 user, and having tracked down his email, his was on a Mac Mini, which
 is considerably newer than my machine.  (Some) PowerPC Mac Minis
 apparently report this:
 gem0 at pci2 dev 15 function 0: Apple Computer GMAC Ethernet (rev. 0x80)
 Not sure about the original reporter's specifics, I couldn't get at the
 dmesg he'd posted, but it seems my revision theory is wrong for Apples.
 > > PS Having tested the GENERIC kernel from HEAD, it seems that gem no
 > > longer supports UDP checksumming?  It did with 4.0.
 >Yes.  I took that out after reading comments in the FreeBSD version of the
 >driver - it notes that the hardware checksum doesn't compensate for the UDP
 >case where the checksum ends up being all 0.  They did leave the ability to
 >enable UDP checksums with `ifconfig gem0 link0`, but I don't see the
 >usefulness of that, so I didn't put it in our driver.  So, we are left with
 >just TCP hardware checksums, and only outgoing on the buggy revisions.
 Ah.  I think I may disable all hardware checksumming on my gem, it
 sounds pretty dodgy.  (But of course, I will test patches.)
 >If you could try the attached patch, that would be great.  If it's OK, I'll
 >check it in and close the PR (if that's OK with you?).
 I'll give it a try tomorrow.
 >PS.  Would you have any interest in the newer gem code being in the 4.0
 >branch?  My test machine is running that, so I have the changes that I've
 >made to the driver working on the branch.  It'll just be a case of sorting
 >out the appropriate revisions for the pull up request.
 Sounds good to me, though I might not be making use of the particular
 code we're talking about.

Home | Main Index | Thread Index | Old Index