एक SFP+ जो साफ dump होता है उस पर Programmer WRITE FAIL देता है: EEPROM मर चुका है या कुछ writes block कर रहा है
हम ज़्यादातर महीनों customer hosts के लिए modules का एक छोटा batch recode करते हैं, कुछ exotic नहीं: original page पढ़ो, host को जो vendor string चाहिए वो लिखो, module switch में डालो और आगे बढ़ो। current batch में से एक module हर write मना कर देता है जबकि वापस बिल्कुल perfectly पढ़ता है, और उसे फेंकने से पहले मैं जानना चाहता हूं कि try करने को कुछ बचा है या नहीं।
Bench:
- SFP breakout board के साथ CH341-class USB programmer
- SFP+ module, diagnostics capable, ठंडा हो या power cycle के बाद, ठीक पढ़ता है
- यही rig एक घंटे पहले उसी tray के तीन और modules लिख चुका था
write दबाते ही tool जो print करता है:
WRITE FAILउसके तुरंत बाद दोबारा पढ़ने पर original page byte for byte वापस मिलता है, तो कुछ भी नहीं गया, आंशिक रूप से भी नहीं।
जो try किया:
- module को फिर से बैठाया और breakout board एक spare से बदला
- पूरे page की जगह एक ऐसे region में एक byte लिखा जिसकी परवाह नहीं, result वही
- confirm किया कि कई power cycles में read stable रहता है, तो wiring marginal नहीं है
क्या ऐसा module जो साफ पढ़ता है पर write कभी accept नहीं करता बस घिस चुका है, या module के अंदर ही कुछ है जो जानबूझकर writes मना कर सकता है?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
साफ पढ़ता है, writes मना, उसके बाद original page वैसा ही बना रहता है। एक घिसे हुए EEPROM का सामान्य व्यवहार ऐसा नहीं होता। मरे हुए cells आपको खराब read-back देते हैं या ऐसा page जिसमें आधा ही write हुआ, ऐसा साफ-सुथरा इनकार नहीं जिसमें सब कुछ अछूता रह जाए।
और चूंकि vendor area के बाहर वो एक byte भी वापस उछल गया, यह chip पर किसी खराब region की बात नहीं, यह part है जो writes को पूरी तरह से लौटा रहा है। कुछ भी तय करने से पहले दो चीज़ें पक्की करने लायक हैं। पहली, module असल में बनाया किसने: जो dump पहले ही ले चुके हो उस page की vendor string देखो, tray पर जो भी label लगा था उसे नहीं। दूसरी, क्या power आते ही, bus पर कोई और चीज़ module से बात करे उससे पहले ही, write दागने पर वो जाता है। संभावित वजह इन जवाबों पर निर्भर करके बदलती है, और उनमें से एक तो fault है ही नहीं।
यह damage से ज़्यादा password protection जैसा लगता है। SFF-8472 एक diagnostics-capable module को किसी भी write से पहले 4-byte password मांगने की इजाज़त देता है। कुछ न भेजो, या गलत भेजो, तो module write का जवाब error से देता है जबकि reads पूरी तरह खुले रहते हैं, जो बिल्कुल आपका WRITE FAIL है जिसमें page बिना बदले वापस आता है। यह part की एक feature है, मरते हुए part का लक्षण नहीं।
आपके bench के लिए इसका मतलब: जो programmer इसके बारे में जानता है वो आपको manufacturer या host password डालने देता है, और अच्छे वाले किसी अनजान password को brute force भी कर देंगे और write के बाद checksums खुद recalculate कर देंगे। CH341-class rig में checksum automation बिल्कुल नहीं है, तो password पार करने के बाद भी checksums खुद ठीक करने होंगे, वरना आपके पास ऐसा module रह जाएगा जिसका page आपको सही लगता है पर host फिर भी मना कर देता है।
आम चेतावनी: मुझे यह मुट्ठी भर modules पर मिला है और वहां password वाला रास्ता काम कर गया, तो किसी भी चीज़ को खारिज करने से पहले अपने part पर try करो।
इसमें जोड़ता हूं: कुछ vendors के लिए passwords असल में secret होते ही नहीं। Ubiquiti transceiver passwords के shared collections घूम रहे हैं जिनमें 0x00001011 जैसी entries और SFPX व QSFP जैसी plain strings हैं, तो अगर module उसी ecosystem से आया है तो brute force के पास जाने से पहले जाने-पहचाने passwords try करने में पांच मिनट ही लगते हैं।
और अगर generic programmer से लड़ने की बजाय ऐसा tool चाहिए जो पूरा flow पहले से जानता हो, तो UACC-SFP-WIZARD वो सस्ता option है जिस तक लोग पहुंचते हैं। यह lab instrument नहीं है, पर module वाला हिस्सा ठीक से संभालता है।
जुड़ा हुआ, Huawei S5731 और S6730 hosts और एक पुराने HP 6120XG के लिए modules recode करने से। जब कमज़ोर कड़ी module नहीं बल्कि cage या breakout होती है, तो लोग सीधे module के pins 4 और 7 पर solder करते हैं, जो I2C की SDA और SCL lines हैं, और cage को तस्वीर से पूरी तरह बाहर रखकर EEPROM drive करते हैं। बदसूरत है, और यह सिर्फ उन parts पर करते हैं जिन्हें खोने के लिए तैयार हो, पर इससे contact problems की एक पूरी class हट जाती है।
यहां जो parts इससे गुज़रे: Finisar FTLX8571D3BCV और FTLX8574D3BCV, Intel SFP+ LR और SR modules, SNR-SFP+W73-3 और SNR-SFP+W37-3, साथ में एक HP J9150A।
आपके case में read कई power cycles में पहले से ही पूरी तरह solid है, तो contact आपका issue नहीं है। पहले password वाला angle पकड़ो।
Password संभावित जवाब है, पर इसे "password type करो और काम खत्म" पर मत छोड़ो, क्योंकि उसके ठीक बाद दो चीज़ें लोगों को काटती हैं।
पहली, कुछ parts पर module power down होने के बाद entry फिर से मांगी जाती है, तो जो script कई pages sequence में लिखती है उसे दोबारा entry के लिए तैयार रहना होगा, यह मानने की बजाय कि एक unlock पूरे session के लिए काफी है।
दूसरी, checksums। CH341-class programmer के साथ इन्हें हाथ से recalculate करते हो। इन्हें stale छोड़ दो तो module फिर भी ठीक पढ़ता है, tool success report करता है, और host फिर भी चुपचाप module मना कर देता है, और तब सब वापस hardware को दोष देने लगते हैं। वो module customer के switch में जाने से पहले page वापस पढ़ो और sums verify करो।