Beware of EMC switches sold as Mellanox SX6XXX on eBay

[RedX1]

Hello

I can only report what I experienced


I found his behaviour was the same for all of the switches that I upgraded – 7 in total - 3 were IBM switches and the other 4 were HP switches

I used the upgrade path and images from the HP website and the Lenovo 3.6.8012 directly from the Mellanox linked site.



The switches work perfectly, so I do not know anything further.



Just another data point.



Good Luck.




RedX1

 

[dodgy route]

Hello

I can only report what I experienced


I found his behaviour was the same for all of the switches that I upgraded – 7 in total - 3 were IBM switches and the other 4 were HP switches

I used the upgrade path and images from the HP website and the Lenovo 3.6.8012 directly from the Mellanox linked site.



The switches work perfectly, so I do not know anything further.



Just another data point.



Good Luck.




RedX1

No arguments here, your points are valid but unsure why yours took so long.
I only did 2x SX6012 but yeh it was as fast as the other updates leading up to 8012. Ah well

 

[Necrotyr]

Righto, @dodgy route and I have managed to get his guide to work on an SX6018, it's now at 3.6.8012 and looking completely like an original MLNX switch

 

[dodgy route]

Righto, @dodgy route and I have managed to get his guide to work on an SX6018, it's now at 3.6.8012 and looking completely like an original MLNX switch

WOO! Now just need someone with a SX6036, need to determine the chassis type to generate the required FRU update script

Small updates to document v1.11 to ack your help @Necrotyr and for confirmation of testing the FRU change to SX6018 along with testing the document out
Link: Converting Mellanox EMC switch to SX60xx v1.11.docx

 

[andvalb]

Hello



I do not have any EMC Mellanox SX6XXX switches, but I have taken several IBM and HP SX1036 and SX6036 Switches through the upgrade process.

The upgrade process using the Web-GUI for the HP images takes around 25 mins to upload the image and then another 25 mins to fully install it.

The upgrade from the HP 3.6.8010 to the Lenovo 3.6.8012 image is not as straightforward. The process is very slow and will take almost 120 mins. (There is a counter).

If you are installing multiple images you will need to remove the old web-images, otherwise the process will fail.

Please see posts 20 and 24 from this thread.
https://forums.servethehome.com/index.php?threads/us-mellanox-sx6036-200.31513/


I hope this helps.



Good luck.





RedX1

You need to check bootstrap EEPROM content.
If it has broken the CPU slows down up to the speed of the snail.

 

[dodgy route]

You need to check bootstrap EEPROM content.
If it has broken the CPU slows down up to the speed of the snail.

I do believe you are on to something here

 

[Necrotyr]

You need to check bootstrap EEPROM content.
If it has broken the CPU slows down up to the speed of the snail.

How'd you do that? I noticed a slowdown on the login in cli around when I got to 3.6.8010, it took way longer to get from login to where I could begin to type commands, same on my 6012 on 3.6.1002.

 

[andvalb]

How'd you do that? I noticed a slowdown on the login in cli around when I got to 3.6.8010, it took way longer to get from login to where I could begin to type commands, same on my 6012 on 3.6.1002.

Use "imd 0x50 0 0x100 0 0x100 2 0 0x100" command from the bootloader.

The output of the command should begin with an:
" 86 82 96 1a d9 80 0 e0 c0 8 23 50 d 5 0 0" for the 166 MHz mem speed
or with " 86 82 96 19 b9 80 0 e0 c0 8 23 50 d 5 0 0 " for the 200 MHz mem speed (can be overclocked!)
or just update bootstrap using "mlxi2c update_bootstrap166" or "mlxi2c update_bootstrap200" command from the shell.

 

[arnbju]

When trying to convert a EMC 6012 using dodgy routes guide I have issues when trying to detect the FRU Bus number

mlxi2c show devs -v
-E- mlxi2c: mi_opend Failed status(MLXI2C_AUTO_DETECT_FAILED:21)

Any ideas?

 

[andvalb]

When trying to convert a EMC 6012 using dodgy routes guide I have issues when trying to detect the FRU Bus number

mlxi2c show devs -v
-E- mlxi2c: mi_opend Failed status(MLXI2C_AUTO_DETECT_FAILED:21)

Any ideas?

Wrong main board fru.
Fru should be updated BEFORE the usage of this command.

 

[arnbju]

The guide uses that command to get the current FRU. From section "Get current FRU" before "Send the updated FRU to the switch"

Or am I missing something?

 

[Necrotyr]

Use "imd 0x50 0 0x100 0 0x100 2 0 0x100" command from the bootloader.

The output of the command should begin with an:
" 86 82 96 1a d9 80 0 e0 c0 8 23 50 d 5 0 0" for the 166 MHz mem speed
or with " 86 82 96 19 b9 80 0 e0 c0 8 23 50 d 5 0 0 " for the 200 MHz mem speed (can be overclocked!)
or just update bootstrap using "mlxi2c update_bootstrap166" or "mlxi2c update_bootstrap200" command from the shell.

mlxi2c update_bootstrap166 just says it's already set, so I guess that's not the problem...

 

[dodgy route]

I

The guide uses that command to get the current FRU. From section "Get current FRU" before "Send the updated FRU to the switch"

Or am I missing something?

I am having a bit of a brain fart, but i believe that command should be able to be used after manufacture, without changing the FRU. According to your info tho... I could be wrong. I added that screenshot in there at a later stage I believe. So try just 1 first. Its not a problem if you try 1 or 8, it wont work if its not there

If you are confirming your output is correct at this point, I will revert the change back to just try 1 first and then 8 if 1 returns no result. Trying to remember back to that step and I think you are right the more i think about it, so it was a mistake to add that info on getting the bus number

 

[andvalb]

I

I am having a bit of a brain fart, but i believe that command should be able to be used after manufacture, without changing the FRU. According to your info tho... I could be wrong. I added that screenshot in there at a later stage I believe. So try just 1 first. Its not a problem if you try 1 or 8, it wont work if its not there

If you are confirming your output is correct at this point, I will revert the change back to just try 1 first and then 8 if 1 returns no result. Trying to remember back to that step and I think you are right the more i think about it, so it was a mistake to add that info on getting the bus number

It can be used if you specify system type by the system type (model) option for the command.
If not this command relies on the main board FRU EEPROM content to detect the type of the system.

 

[dodgy route]

It can be used if you specify system type by the system type (model) option for the command.
If not this command relies on the main board FRU EEPROM content to detect the type of the system.

Excellent, I may change it to that instead. Totally slipped my mind mlxi2c allows setting system type

 

[arnbju]

I tried with "-s SX6012" as well, but it did not work. Just using 1 to make a copy worked. But after copying the patched FRU the mlxi2c command does still not work. Might need a reboot or something else?

mlxi2c show devs -v
Oct 13 21:48:59 INFO    LOG: Initializing SX log with STDOUT as output file.
Oct 13 21:48:59 ERROR   ACCESS_REG: Failed to open the DPT shared memory
Oct 13 21:48:59 ERROR   ACCESS_REG_INIT: Failed loading the DPT
Oct 13 21:48:59 ERROR   ACCESS_REG: Failed to open the DPT shared memory
-E- mlxi2c: mi_opend Failed status(MLXI2C_SX_CMDIF_INIT_FAILED:63)

EDIT: After flashing new firmware and rebooting it works

 

[dodgy route]

I just tried all the supported systems in the manufacturing version and none actually work... so there is that, best to just move on it...
As to it not working, yes a reboot is needed but its not required yet, just continue working through the other steps after this step was completed.

Ill update guide to remove "getting the bus number" at this step

 

[dodgy route]

Just out of curiosity, I checked 3.4.0012 and Sx6012 and SX6018 system types are supported by that version mlxi2c
Not sure what my take on that is but it must use some other generic method to do it that I am just not sure now, I doubt HP modified the manufacturing process in any way to exclude SX6012 and SX6018

Doco is updated to v1.12, thanks @arnbju for noting the issue, its now removed from get current FRU heading

 

[bigb]

Just used the dodgy route method to update a 'new in box' EMC 6012 that I tried the old method on; and got as far as not being able to login to the full mlx-linux to flash the ASIC; so I went back to square one.

Once you have the environment setup, this method is quite painless.. I would say that the FRU reprogram process feels a bit clunky but it worked; i couldn't get my files to match up with the byte counts in the documentation, but after much checking and rechecking, the FRU conversion worked no problem.

Does anyone know if there is a way to make the command line fan speed changes that SGS referenced on post #739 persist between reboots?

I would prefer to add this line to a startup script; than hexedit the tc file..

 

[Necrotyr]

Does anyone know if there is a way to make the command line fan speed changes that SGS referenced on post #739 persist between reboots?

I would prefer to add this line to a startup script; than hexedit the tc file..

Look a page or two back, you can from _shell mount the filesystem to RW and edit RC.local, there you can throw the script.