dmesg output not as expected

Dan Langille dan at langille.org
Wed Jul 29 13:22:51 UTC 2015


> On Jul 28, 2015, at 11:56 PM, Scott Long <scott4long at yahoo.com> wrote:
> 
> 
>> On Jul 28, 2015, at 8:18 PM, Dan Langille <dan at langille.org> wrote:
>> 
>> After rebooting this server, I see this in /var/run/dmesg.  Why does it change?
>> 
>> ch0 at mpt0 bus 0 scbus14 target 3 lun 0
>> ch0: <COMPAQ MSL5000 Series 0520> Removable Changer SCSI-2 device
>> ch0: Serial Number 3G22JJP38S46
>> ch0: 20.000MB/s transfers (10.000MHz DT, offset 15, 16bit)
>> ch0: 25 slots, 1 drive, 1 picker, 1 portal
>> ch0: quirks=0x2<NO_DVCID>
>> 
>> I was hoping to get more through put on this newer system with a different card.  From what I see, my speed is only half of what it was.
>> 
>> I'm using a PCI-E 3.0 X8 (in X16) slot. Have I missing something?
>> 
> 
> The LSI controllers do Domain Validation.  That means that they send a series of test commands to each target to try to determine a safe speed to negotiate to.  The theory is that these test commands will determine whether the target’s speed needs to be downshifted in order to avoid problems with bad cables and bad connectors.  It’s part of the Ultra320 spec, and I think it was in the Ultra160 spec too, but was rarely implemented there.  It’s possible that the DV routine is telling the card that these devices need to have their negotiated speed reduced, and that the results it gets are a bit on-the-fence at times and cause different observed speeds.
> 
> It’s been a long time since I worked with DV, so my memory is a bit fuzzy.  The Adaptec hardware never did DV other than a really simple algorithm in the BIOS for the U320 cards, and I’m pretty sure that the Symbios cards pre-date DV all-together.  I think that the MPT controllers do DV in the firmware at boot, and the driver just reads the results and uses that for the default negotiation settings.  I don’t see much in the MPT driver for debugging this, but I recall that the DV algorithm that LSI used was pretty naive and overly-aggressive at forcing down negotiation.  You might want to look at what options the LSI BIOS offers, or if you can use camcontrol to change the negotiation up to where you think it should be.

I went into the BIOS and took photos of what I found.  They seem to be set to optimal values.

Do you see anything I should investigate further?

These photos are not necessarily in any particularly order.

https://dl.dropboxusercontent.com/u/24218593/LSI-BIOS-1.jpeg
https://dl.dropboxusercontent.com/u/24218593/LSI-BIOS-2.jpeg
https://dl.dropboxusercontent.com/u/24218593/LSI-BIOS-3.jpeg
https://dl.dropboxusercontent.com/u/24218593/LSI-BIOS-4.jpeg

— 
Dan Langille
http://langille.org/







More information about the freebsd-scsi mailing list