On Wed, Jun 11, 2014 at 03:49:16PM +0100, Phil Mayers wrote: > On 11/06/14 15:01, Chuck Anderson wrote: > > >Jun 10 11:40:54 ex4200 chassism[1293]: XCVR: Unit 0, SFP+ of type 0 EEPROM > >is Mis Programmed!! > > Yeah, this was the one that caught my eye. I wonder if it's choking > on unknown values in the EEPROM.
After much investigation, and thanks to Juniper not locking down access to the internal debugging tools on JUNOS, I was able to determine that bytes 3-10 of the SFP ID EEPROM of optic I'm using are coded as all 0's. My reading of the SFF-8472 MSA says that this is invalid: "Transceiver Compliance Codes [Address A0h, Bytes 3-10] The following bit significant indicators define the electronic or optical interfaces that are supported by the transceiver. At least one bit shall be set in this field." The top half of byte 3 is defined as follows, and I would expect any MSA Ethernet optic to have at least one of these bits set, even CWDM/DWDM optics: Byte Bit Description 3 7 10G Base-ER 3 6 10G Base-LRM 3 5 10G Base-LR 3 4 10G Base-SR My optic vendor doesn't agree and says that those bits only refer to "grey" optics--standard wavelengths 850nm or 1310nm, and says that it is VALID to have no bits set all all in bytes 3-10. I'm guessing that the SFP driver in EX4200 doesn't like this, but the one in MX doesn't care. I tried changing the values using "xcvrpeek" and "xcvrpoke" (and "i2cpeek"/"i2cpoke"). Reads work fine, writes fail with -EIO in dmesg and the values don't change when read back. I guess the optic is "locked" from writing changes to the EEPROM without some sort of OEM password or something. _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
