गड़बड़ी का कोड: E0200

कैटगरी: रनटाइम: कोर प्रोसेस अचानक रुक गई

इस गड़बड़ी से पता चलता है कि टीपीयू कोर ने निर्देशों को समय से पहले ही पूरा करना बंद कर दिया है. यह एक गंभीर गड़बड़ी की स्थिति है. इसमें हार्डवेयर, ठीक न हो सकने वाली गड़बड़ी, हार्डवेयर की शर्तों का उल्लंघन या कंपाइलर से जनरेट की गई रनटाइम पुष्टि की वजह से जान-बूझकर इंटरप्ट किए जाने की वजह से रुक जाता है.

गड़बड़ी के मैसेज का उदाहरण:

INTERNAL: Accelerator device halted prematurely, perhaps due to an on-device check-failure. Node 0 halted unexpectedly at tag:pc TensorCoreSequencer:1:0x1d9 ...

XLA बैकएंड: टीपीयू

खास जानकारी

XLA, JAX प्रोग्राम को असेंबली के निर्देशों के एक क्रम में कंपाइल करता है. रनटाइम के दौरान, टीपीयू डिवाइस इन निर्देशों को क्रम से लागू करता है. टीपीयू हार्डवेयर में ऐसी समस्या आने पर "कोर अचानक बंद हो गई" गड़बड़ी होती है जिसे ठीक नहीं किया जा सकता. इस वजह से, आगे की प्रोसेस नहीं हो पाती और कोर को "HALTED" स्थिति में ले जाना पड़ता है.

यह गड़बड़ी, हार्डवेयर में खराबी, कंपाइलर की गड़बड़ियों या उपयोगकर्ता के कोड से जुड़ी समस्याओं (खास तौर पर कस्टम कर्नल में) की वजह से हो सकती है. इसलिए, गड़बड़ी की वजह का पता लगाने के लिए, आपको लॉग मैसेज का ध्यान से विश्लेषण करना होगा.

डीबग करना

इस गड़बड़ी को ठीक करने के लिए, आपको सबसे पहले यह पता लगाना होगा कि इन तीन खास स्थितियों में से किस वजह से, प्रोसेस अचानक रुक गई. नीचे दिए गए खास टेक्स्ट सिग्नेचर के लिए, अपने लॉग देखें.

पहला उदाहरण: इंफ़्रास्ट्रक्चर से जुड़ी समस्याएं (हार्डवेयर/नेटवर्क/पावर)

हस्ताक्षर: लॉग में साफ़ तौर पर observed errors are: [Hardware] या observed errors are: [Network] या observed errors are: [Power] लिखा होना चाहिए.

इससे पता चलता है कि फ़िज़िकल इन्फ़्रास्ट्रक्चर में कोई गड़बड़ी हुई है. इसका आपके सॉफ़्टवेयर या मॉडल लॉजिक से कोई लेना-देना नहीं है. टीपीयू चिप, चिप को कनेक्ट करने वाला नेटवर्क फ़ैब्रिक या पावर सप्लाई काम नहीं कर रही है.

  • फिर से कोशिश करें: अगर समस्या वोल्टेज में अचानक गिरावट या नेटवर्क में रुकावट की वजह से हुई है, तो फिर से कोशिश करने पर समस्या ठीक हो सकती है.
  • खराब नोड की पहचान करें और उन्हें हटाएं: अगर गड़बड़ी किसी खास टास्क या होस्ट पर बनी रहती है, तो हो सकता है कि हार्डवेयर में कोई खराबी हो. अपने क्लस्टर मैनेजमेंट टूल का इस्तेमाल करके, समस्या वाले नोड को "ड्रेन"/"कॉर्डन" करें. इसके बाद, अपने काम को ठीक नोड पर फिर से शुरू करें.

दूसरी स्थिति: हार्डवेयर से जुड़ी ज़रूरी शर्तों का उल्लंघन

हस्ताक्षर: लॉग में observed errors are: [User] लिखा होता है.

इससे पता चलता है कि XLA कंपाइलर ने ऐसा निर्देश जनरेट किया है जिसने हार्डवेयर की एक ऐसी शर्त का उल्लंघन किया है जिसका उल्लंघन नहीं किया जा सकता. उदाहरण के लिए, ऐसा निर्देश जो एचबीएम या स्क्रैचपैड मेमोरी पर सीमा से बाहर के मेमोरी पते को ऐक्सेस करने की कोशिश कर रहा है. इसे "उपयोगकर्ता" के तौर पर लेबल किया गया है. हालांकि, ऐसा बहुत कम होता है कि उपयोगकर्ता के कोड की वजह से यह समस्या हो.

  • XLA से जुड़ी गड़बड़ी की शिकायत करें: यह कंपाइलर से जुड़ी गड़बड़ी हो सकती है. कंपाइलर को ऐसे निर्देश कभी नहीं देने चाहिए जो हार्डवेयर की खास बातों का उल्लंघन करते हों. कृपया गड़बड़ी की रिपोर्ट दर्ज करें.

तीसरा उदाहरण: XLA कंपाइलर से जनरेट किए गए ऐसेटशन फ़ेल हो गए

हस्ताक्षर: गड़बड़ी के मैसेज में, कंपाइलर से जनरेट किए गए उस दावे के बारे में खास जानकारी होती है जो पूरा नहीं हो सका. इन कीवर्ड को खोजें:

  • BoundsCheck, scheckne, scheckeq, schecklt, scheckge, scheckbetween

इससे पता चलता है कि कंपाइल किए गए प्रोग्राम में कंपाइलर से जनरेट किया गया दावा, एक्ज़ीक्यूशन के दौरान पूरा नहीं हुआ. गड़बड़ी के मैसेज का विश्लेषण करके, उसके सब-टाइप का पता लगाएं.

तीसरा विकल्प: लॉन्च ग्रुप का मेल न खाना

गड़बड़ी के मैसेज का उदाहरण:

Core halted unexpectedly: INTERNAL: Accelerator device halted prematurely, perhaps due to an on-device check-failure. Node 0 halted unexpectedly at tag:pc TensorCoreSequencer:1:0x1d9 (from TensorCoreSequencer:1:0x309): scheckne: An unexpected leader shows up in the launch group with a different launch id than the current group leader.

वजह: यह गड़बड़ी आम तौर पर, एक से ज़्यादा होस्ट वाले टीपीयू एनवायरमेंट में होती है. इससे पता चलता है कि टीपीयू कोर, जो एक ही प्रोग्राम को सिंक्रनाइज़ तरीके से (एक "लॉन्च ग्रुप" के तौर पर) एक्ज़ीक्यूट करती हैं वे सिंक से बाहर हो गई हैं. खास तौर पर, टीपीयू कोर ने किसी ऐसे सिंक्रनाइज़ेशन ग्रुप में शामिल हुआ है जिसका प्रोग्राम आइडेंटिफ़ायर, मौजूदा ग्रुप लीडर से अलग है. इससे पता चलता है कि होस्ट में प्रोग्राम अलग-अलग हैं.

  • XLA फ़्लैग की पुष्टि करें: पक्का करें कि सभी होस्ट एक ही XLA_FLAGS का इस्तेमाल कर रहे हों.
  • JAX प्रोग्राम की जांच करें: जांच करें कि सभी होस्ट, एक जैसे JAX प्रोग्राम को लागू कर रहे हों. Docker इमेज, libtpu वर्शन वगैरह की पुष्टि करें

तीसरा परिदृश्य: सीमा की जांच पूरी नहीं हुई

गड़बड़ी के मैसेज का उदाहरण:

Core halted unexpectedly: INTERNAL: Accelerator device halted prematurely, perhaps due to an on-device check-failure. Node 0 halted unexpectedly at tag:pc TensorCoreSequencer:23:0x292 (from TensorCoreSequencer:23:0xd74a): BoundsCheck 92 [deref of %s931] for %937 = dma.hbm_to_vmem [thread:$0]  /*hbm=*/%s931, /*size_in_granules=*/16384, /*vmem=*/%s935, /*dst_syncflagno=*/%s860, /*src_stride=*/512, /*dst_stride=*/128, /*steps_per_stride=*/8

वजह: प्रोग्राम ने तय सीमा से बाहर की मेमोरी को ऐक्सेस करने की कोशिश की. गड़बड़ी के मैसेज में अक्सर मेमोरी ऐक्सेस करने के टाइप (जैसे, dma.hbm_to_vmem) और पते के हिसाब-किताब के बारे में जानकारी शामिल होती है.

  • कस्टम कर्नल को डीबग करना: अगर Pallas का इस्तेमाल किया जा रहा है, तो इंडेक्स कैलकुलेशन की जांच करें. टेंसर इंडेक्स की पुष्टि करने के लिए, pl.debug_print या checkify का इस्तेमाल करें.
  • शार्डिंग की जांच करें: पक्का करें कि शार्डिंग एनोटेशन, टेंसर शेप के मुताबिक हों.

Scenario 3.C: Mosaic/Pallas के साथ सिंक करना

गड़बड़ी के मैसेज का उदाहरण:

Core halted unexpectedly: INTERNAL: Accelerator device halted prematurely, perhaps due to an on-device check-failure. Node 0 halted unexpectedly at tag:pc TensorCoreSequencer:21:0xae5 (from TensorCoreSequencer:21:0x54c5): Semaphore (scratch argument 1) has a nonzero value upon exit from a Mosaic kernel. Make sure every DMA is awaited, and every semaphore signal is paired with a wait.

वजह: यह गड़बड़ी, Mosaic कंपाइलर से जनरेट किए गए कोड से जुड़ी है. इस कंपाइलर का इस्तेमाल Pallas JAX करता है. इससे पता चलता है कि कस्टम कर्नल में सिंक करने से जुड़ी कोई समस्या है. टीपीयू, डिपेंडेंसी मैनेज करने के लिए सेमाफ़ोर का इस्तेमाल करते हैं. जैसे, यह पक्का करना कि डीएमए का इस्तेमाल करने से पहले वह पूरा हो गया हो. इस गड़बड़ी से पता चलता है कि सेमाफ़ोर पर सिग्नल का सही तरीके से इंतज़ार नहीं किया गया.

  • ऑडिट सिंक्रनाइज़ेशन: पक्का करें कि हर dma_start का एक मेल खाने वाला dma_wait हो.
  • सेमाफ़ोर की जांच करें: पुष्टि करें कि सेमाफ़ोर सिग्नल और इंतज़ार के समय को सख्ती से जोड़ा गया हो.

अन्य समस्याएं

अगर आपका गड़बड़ी का लॉग, पहले, दूसरे या तीसरे परिदृश्य से मेल नहीं खाता है (यानी कि "observed errors" नहीं हैं, "scheck" टैग नहीं हैं, और कोई खास सीमाएं/सेमाफ़ोर मैसेज नहीं हैं):