On Fri, Jan 15, 2010 at 1:25 PM, Adam Cheal <ach...@pnimedia.com> wrote: > Initial post didn't make it across to the Mailman interface, so here we go > again: > > Seems I've hit a bug in more recent builds of OpenSolaris regarding setting > large mtu values (i.e. jumbo frames support) on systems with multiple e1000g > ports. This has happened across the board on all of our systems that use > integrated e1000g ports, but not those that use nge (i.e. Thumpers), > therefore I feel this problem is isolated to e1000g. Everything was working > fine on b118, but as soon as we moved to later builds (I've tried > b126->b130), the second NIC shows a maximum possible settable MTU of 1500, > instead of the expected 9216. Booting back into b118 makes it work again. > I've searched the release notes for all builds > 118 to see if there was any > mention of MTU related fixes in e1000g or dladm but could find nothing. > > I've attached a full "prtconf -v" output from b130. > > First, build 118 dladm output: > > # dladm show-linkprop -p mtu > LINK PROPERTY PERM VALUE DEFAULT POSSIBLE > e1000g0 mtu rw 9000 1500 1500-9216 > e1000g1 mtu rw 9000 1500 1500-9216 > > Then once I reboot into b126 or greater: > > # dladm show-linkprop -p mtu > LINK PROPERTY PERM VALUE DEFAULT POSSIBLE > e1000g0 mtu r- 1500 1500 1500-9216 > e1000g1 mtu r- 1500 1500 1500 > > The differences I see are: > > 1. The "PERM" column changes from "rw" to "r-". Not sure if that has any > bearing. > 2. A side effect of the image-update to the new builds seems to be that it > resets the per-adapter configured value of MTU back to the default of 1500. I > can "dladm set-linkprop" and change the value back to "9000" for e1000g0, but > not e1000g1. > 3. The POSSIBLE mtu range for the second port (e1000g1) does not show the > proper range. Obviously, "dladm set-linkprop -p mtu="9000" e1000g1" fails. > > I have changed the /kernel/drv/e1000g.conf to "enable" jumbo frames via: > > MaxFrameSize=3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3; > > ...but this conf setting seems to be ignored anyway. No hardware > configuration has changed on these systems or the switches they connect to. > > Thoughts/suggestions/pointers? > -- > This message posted from opensolaris.org > _______________________________________________ > networking-discuss mailing list > networking-discuss@opensolaris.org >
Don't know how much this helps, but two e1000g devices appear to be slightly different variants of the chip (looking at the source, it appears there are a _lot_ of different versions out there all with the same name). e1000g0 has a device id of 0x10bd while e1000g1 has a device id of 0x108b (if you look through the prtconf output, you can see it in there) Looking at the driver source, the _default_ MTU size is what's controlled by the MaxFrameSize property. The actual maximum MTU size is ultimately set based on the device id (any requests over the maximum size result in the MTU being set to the max). In the case of the e1000g1, it believes it should be the traditional 1500 bytes. I don't have access to any of the specs for the chips from Intel, so I don't know if the driver is making the correct assumption or not for the 2nd device. I've copied driver-discuss in case the relevant people (who would know) lurk there and not on networking-discuss. _______________________________________________ networking-discuss mailing list networking-discuss@opensolaris.org
