Search results

Right, that makes sense. But enabling it in SAS drives doesn't have any difference in enabling it in SATA drives in terms of performance and risk, correct? I'm running badblocks against a used HGST SAS drive I got and was surprised that the write speed was just 25MBps. I used smartctl to enable...

So then why is write caching enabled by default on SATA drives? Does that mean SATA disks are designed to be volatile storage since they are targeted more for consumers?

So to confirm, it is not a thing these days? And you can't implement it?

I'm having a similar situation with an HGST drive that I just bought. Initially, I was trying to do a background long smartcl test but it was erroring out that it is an unsupported scsi command. So I tried running a foreground long (with the -c switch) test but I didn't know if it didn't have...

So what is the consensus here? Does SR-IOV make sense for HBA cards like the Dell PERC H310?

Gotcha. Here's all data I see in a `smartctl -a /dev/sdb` command: smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-21-amd64] (local build) Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org === START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION === Sending command...

They can or can't? Can they be cross-flashed with an OEM HUH728080AL4200 firmware? The physical label of the drive says HUH728080AL4200.

Is the HUH72808CLAR8000 a third-party/non-generic HGST drive? Is there a new firmware for it? I'm having issues running a SMART long test against this drive and get this error: Long (extended) offline self test failed [unsupported field in scsi command]

So what is this drive? HUH72808CLAR8000 Is there a new firmware of it? I'm having issues running a SMART long test against this drive and get this error: Long (extended) offline self test failed [unsupported field in scsi command]

Can anyone confirm if there's a new firmware for these HUH72808CLAR8000 drives? I just bought one and when I run a SMART long test against it, I get this: Long (extended) offline self test failed [unsupported field in scsi command] A lot of people are saying that this is because the firmware...

How will it not work properly though? I'm seeing a lot of users using this card with sriov? I mean it works for me too but with an older fw?

That is exactly what I did actually, buy a CX4. So it's really too late for me to tinker with this CX3 to make sriov work.

All the guides I see are showing how to cross-flash from an OEM (IBM, Dell, etc.) to a stock Mellanox firmware, not the other way around which is what we're tying to do here. Can you expound on what you're trying to point out here? Are you saying there's an older IBM MLX fw that I can use to...

Oops, my bad. I'll have to try this in one of my cards later. It should be easy to do on the card on my Windows machine but I'm not sure if it's possible to do this on the card in my Synology NAS.

Were you able to confirm if the IBM fw you linked to is just for vpi cards (not en)?

@i386 how do you change the PSID if you don't have the mlx firmware for 2.42.5032?

If you enable SRIOV though, do you need to assign the VLAN and the unique MAC per VF? If so, what mft command does this?

When flashing OEM CX3 cards with the fw from Nvidia, do the GUID's and MAC's get rewritten to a generic one which makes us want to flash with the switch that writes a MAC address to the card or something?

MCX312A-XCBT (dual SFP+, CX3 non-pro) MCX312B-XCCT (dual SFP+, CX3 pro) For anyone using these cards, can you guys confirm if mlxconfig (from the MFT tools) works for querying and setting their parameters (for setting up SRIOV). I have to replace my MCX311A-XCAT (single SFP+, CX3 non-pro)...

I just found why this is happening. It seems to be an issues with the mft tools and the single port CX3 (as discussed here). The solution is to generate an image with a modified ini (to enable sriov) but the mlx fw file you can use with that is older (2.40.5030) than the latest available bin...