I was talking about the packet size at link level. The standard FC (original) max frame size is 2148 which is a 2112 payload (data handed over the bus from the OS) plus 36 bytes of frame construction (header, footer, checksum, et al) put on by the adapter in order to transmit to the target. That was always standard.

Then, because the link could become a bottle neck with packets queuing for transmission, the standard was amended to allow "jumbo" packets (basically the amalgamation of multiple packets) of up to 9000 bytes which after frame construction added 36 bytes to that giving a max frame size of 9036.

Some adapters support jumbo and some don't. Some allow you to switch on/off support in the HBA BIOS, and some don't.

Needless to say, if one HBA is supporting jumbo and the other not, then a frame can arrive that cannot be unpacked.

Now, further up the netstack (in the OS) the payload (just the data element) will be a lower number, perhaps 2048, I'm not sure. That in turn will be included inside a larger packet (perhaps 64 bytes larger) to construct the payload (2112) to be handed down to the HBA for transmission. Therefore, as I said before, the size and number of buffers allocated by the OS also plays a part in this. If the buffer size is configured too small then the incoming packets won't fit in and the packet cannot be captured and unpacked.

However, with a LINK ERROR reported (by the HBA through the hostbus to the OS) I think that the HBA's are having difficulty. Do you have any other cards of the same type on site? We cannot rule out a hardware fault with one of the HBA's. If you have spares I would certainly give it a shot.

So to answer your question, no, I don't understand how the QL is offering just 512, 1024 and 2048 as max frame size options. I'll do some research on that. Perhaps you should give QL support a call to discuss that point.