خطای فراموش‌نشدنی اینتل؛ ماجرای باگ معروف پنتیوم

از آنجایی که تنها پنج سلول از ۱٬۰۶۶ سلول مقدار نادرست داشتند، محاسبات تقسیم ممیز شناور معمولاً تا حداقل رقم چهارم درست بودند و شاید به همین دلیل این باگ بیش‌از یک سال ناشناخته ماند.

به دلیل ماهیت بازگشتی الگوریتم SRT، مقادیر خطا ممکن بود در طی تکرارهای متوالی یک عملیات تقسیم انباشته شوند. در بدترین حالت، خطا می‌توانست تا چهارمین رقم معنادار یک عدد اعشاری افزایش یابد. بااین‌حال، احتمال وقوع تصادفی این حالت تنها حدود ۱ در ۳۶۰ میلیارد است.

شاید این احتمال بسیار کوچک به‌نظر بیاید، اما به دلیل تعداد زیاد عملیات در هر ثانیه، احتمال وقوع خطا، زیادتر می‌شود. درنهایت، توماس نایسلی، استاد ریاضیات از کالج آمریکایی لینچبورگ این باگ را کشف کرد؛ او محاسبات را بر روی چندین کامپیوتر انجام می‌داد که یکی از آن‌ها از پنتیوم استفاده می‌کرد.

در تاریخ ۲۹ اکتبر، نایسلی کشف خود را با اندرو شولمن، نویسنده‌ی کتاب‌های «آموزش ویندوز» و «آموزش داس»، به‌اشتراک گذاشت. از آنجا که شولمن به یک کامپیوتر پنتیوم دسترسی نداشت، در تاریخ ۱ نوامبر با ریچارد اسمیت، بنیانگذار شرکت فار لپ، تماس گرفت و از او خواست تا سیستم خود را برای این باگ تست کند. شرکت فار لپ به‌سرعت با استفاده از ماشین‌حساب ویندوز و یک برنامه‌ی ساده به زبان C، وجود باگ در عملیات تقسیم را تأیید کرد.

ریچارد اسمیت همچنین پیام توماس نایسلی را به اینتل و چند شرکت بزرگ دیگر آن زمان، مانند مایکروسافت، Metaware و Watcom ارسال کرد. او همچنین این خبر را در فروم Canopus منتشر کرد تا خبر وجود باگ پردازنده‌های پنتیوم برای اولین‌بار در فضای عمومی پخش شود. در عرض ۲۴ ساعت، بیش‌از ۱۰ تأییدیه از وجود این باگ در سیستم‌های مختلف مبتنی‌بر پنتیوم دریافت شد.

در یک سخنرانی در سال ۲۰۱۹، جان رومرو، یکی از سازندگان بازی Quake، هنگام بازنگری در توسعه‌ی این بازی توضیح داد که چگونه برنامه‌نویسان شرکتش توانستند این باگ را به‌طور مکرر و پیوسته بازتولید کنند. آن‌ها ساعت‌ها صرف یافتن شرایطی کردند که برای ایجاد این باگ لازم بود؛ باگی که باعث می‌شد بخش‌هایی از یک مرحله‌ی بازی به‌طور غیرمنتظره‌ای از برخی زوایای دوربین دیده شوند.

جالب این است که در داستان سقوط شرکت سایریکس دیدیم که استودیوی بازی‌سازی id Software چگونه با جانبداری از اینتل، بازی Quake را فقط برای پنتیوم بهینه‌سازی کرد. اینجاست که ابعاد جدیدی از جهت‌گیری id Software در آن سال‌ها روشن می‌شود.

تا اکتبر ۱۹۹۴، نایسلی مطمئن شد که این باگ صرفا در خود پردازنده‌ی پنتیوم نهفته است و نه برنامه‌هایی که روی پردازنده اجرا می‌شوند. او با نوشتن نامه‌ای به اینتل دلایل خود را روشن کرد و در ادامه جامعه‌ی علمی را در جریان کشف این باگ گذاشت؛ اما به‌لطف اینترنت نوپای آن زمان، باگ FDIV به‌سرعت به دانش عمومی تبدیل شد.

خطای FDIV در پردازنده پنتیوم نه‌تنها در دنیای فناوری سروصدا به پا کرد، بلکه به یک هیاهوی کامل رسانه‌ای تبدیل شد. روزنامه‌ها، شبکه‌های تلویزیونی و حتی برنامه‌های گفتگوی شبانه نتوانستند از طنزپردازی درباره‌ی این باگ خودداری کنند. ناگهان همه به کمدین‌هایی تبدیل شدند که درباره‌ی کامپیوترهایی که نمی‌توانند محاسبات ساده‌ی ریاضی انجام دهند، شوخی می‌کردند. این داستان آنقدر بزرگ شد که خبرگزاری CNN حتی یک بخش ویژه برایش پخش کرد. مجری برنامه‌های شبانه، جی لنو، با کنایه گفت:

می‌دانید، قصد داشتم یک پردازنده پنتیوم بخرم، اما بعد شنیدم که نمی‌تواند از پس محاسبات ساده‌ی ریاضی برآید. فکر کردم، خب چه فایده‌ای دارد؟

اما عجیب اینجاست که مهندسان اینتل قبل از اینکه نامه‌ی نایسلی را دریافت کنند، از مشکل آگاه بودند و برای رفع آن تلاش می‌کردند. در ابتدا اینتل استدلال کرد که این باگ فقط در موارد نادر رخ می‌دهد و کاربران عادی را درگیر نخواهد کرد.

بااین‌حال، در ابتدا هیچ برنامه‌ای برای تعویض پنتیوم‌های تحت تأثیر باگ وجود نداشت، زیرا اینتل معتقد بود که این موضوع چندان مهم نیست.

یک کاربر عادی که از اکسل استفاده می‌کند، ممکن است تنها یک بار در هر ۲۷,۰۰۰ سال استفاده، با این باگ جزیی مواجه شود.

– اینتل

اما اینتل واقعاً اشتباه می‌کرد! با انتشار اخبار مربوط‌به این باگ، افراد بیشتری شروع به آزمایش پردازنده‌های پنتیوم خود کردند و کسانی که خواهان یک تراشه‌ی جایگزین بدون باگ بودند، به اینتل نشان دادند که واقعاً با آن مواجه شده‌اند.

نگرش اینتل نسبت‌به باگ FDIV واکنش‌های شدیدی به‌همراه داشت و شریک تجاری دیرینه‌اش IBM، فروش کامپیوترهای مجهز به اینتل را متوقف کرد. البته مدتی بعد انگیزه‌ی IBM برای این تصمیم توسط برخی از کارشناسان صنعت زیر سوال رفت؛ زیرا IBM در آن زمان پردازنده‌های PowerPC را تولید می‌کرد که رقیب مستقیم محصولات اینتل بودند.

اینتل با یک کابوس رسانه‌ای مواجه شد. غول دنیای تراشه باید کاری می‌کرد تا اعتماد مشتریانش را دوباره به‌دست ‌آورد. اینتل مشکل را در گزارش سالانه‌ی خود در سال ۱۹۹۴ پذیرفت و اعتراف کرد که در یک «جنجال» گرفتار شده است.

سرانجام در ۲۰ دسامبر ۱۹۹۴، طرحی به نام «برنامه‌ی تعویض پردازنده‌ی پنتیوم» راه‌اندازی شد. تحت این برنامه، اینتل پیشنهاد کرد که هر پردازنده‌ی پنتیوم معیوب را به صورت رایگان تعویض می‌کند. این اقدام برای اینتل ۴۷۵ میلیون دلار هزینه دربرداشت (معادل ۹۴۰ میلیون دلار در سال ۲۰۲۴)، اما برای حفظ اعتبار، چاره‌ی دیگری نبود.

تولیدکنندگان نرم‌افزار برای رفع باگ پنتیوم، بسته‌های نرم‌افزاری مختلفی ارائه کردند. یکی‌از این الگوریتم‌ها که در مقاله‌ای در مجله IEEE Computational Science & Engineering شرح داده شده، به این صورت عمل می‌کند که مقسوم‌علیه‌هایی را که به سلول‌های آرایه‌ی منطقی قابل برنامه‌ریزی دسترسی داشته‌اند، بررسی می‌کند. اگر الگوریتم تشخیص دهد که حاصل تقسیم از سلول‌های حاوی مقدار اشتباه استفاده کرده است، یک مرحله به عقب برگشته و صورت و مخرج تقسیم را به ترتیب در ۱۵ و ۱۶ ضرب می‌کند. این عملیات ریاضی سبب می‌شود که هر مرحله از تقسیم از محدوده‌ی باگ‌دار خارج شود.

این اصلاح البته هزینه‌ای در سرعت اجرا دارد که در بدترین حالت، برنامه‌‌ی عملیات تقسیم با مقسوم‌علیه‌های مشکل‌دار را در دو برابر زمان عادی اجرا می‌کند؛ زیرا هر FDIV به جای ۴۰ سیکل کلاک حدود ۸۰ سیکل کلاک زمان می‌برد. از آنجایی که عملیات تقسیم در واحد ممیز شناور در بیشتر برنامه‌ها نادر است، کاهش سرعت معمول با نصب این اصلاح معمولاً یک درصد یا کمتر بود.‏

مایکروسافت برای برطرف کردن این باگ راه‌حل‌هایی در سطح سیستم‌عامل ارائه کرد. ابزارهایی که همراه با هسته‌ی سیستم‌عامل ویندوز ارائه می‌شدند، وجود باگ را بررسی و در صورت کشف آن، واحد پردازش ممیز شناور (FPU) را غیرفعال می‌کردند.

اینتل به‌خاطر باگ FDIV برای اولین‌بار مجبور به فراخوانی پردازنده‌هایش شد. این باگ همچنین اولین اشتباه سخت‌افزاری بزرگ اینتل بود، اما قطعاً آخرین آن نبود. سال ۲۰۲۴ نه تنها سی‌امین سالگرد کشف باگ FDIV بود، بلکه سالی بود که اینتل ناپایداری پردازنده‌های نسل ۱۳ و ۱۴ را تأیید و علتش را به وجود باگ در میکروکد آن‌ها نسبت داد که باعث می‌شد پردازنده درخواست ولتاژ بالاتر از حد مجاز داشته باشد و درنتیجه خارج از محدوده‌ی امن خود کار کند.

خوشبختانه اینبار، اینتل نیازی به فراخوانی تمام پردازنده‌های این سری نداشت، اما تراشه‌های آسیب دیده را از طریق ضمانت فروش جایگزین کرد. این شرکت همچنین یک میکروکد جدید از طریق بایوس‌های مادربرد ارائه داد تا از وقوع مجدد باگ جلوگیری کند.

اگرچه باگ FDIV نمی‌توانست با نرم‌افزار یا به‌روزرسانی‌های فرم‌ور‌ برطرف شود، دست‌کم هیچ پردازنده‌ای را از کار نینداخت. باتوجه به اینکه صاحبان پنتیوم به ندرت با باگ FDIV مواجه می‌شدند، می‌توان گفت که باگ ولتاژ بالای رپتور لیک کاربران بیشتری را تحت تأثیر قرار داده است، اگرچه تمام پردازنده‌ها دچار آسیب نشدند.

باگ FDIV پنتیوم، درس‌های مهمی به شرکت‌های تکنولوژی آموخت. اول از همه، اهمیت کنترل کیفیت و انجام تست‌های دقیق پیش از عرضه‌ی محصول بود. این باگ به‌دلیل نقص در الگوریتم تقسیم اعداد ممیز شناور ایجاد شده بود و اگرچه اینتل تست‌هایی انجام داده بود، مسئله این بود که اهمیت این خطا را کمتر از واقعیت نشان داد.

همین کم‌اهمیت جلوه دادن تاثیر باگ پنتیوم انتقادهای زیادی به همراه داشت. اینتل ابتدا تمایلی به اطلاع‌رسانی دقیق درباره‌ی این باگ نداشت و مشتریان احساس می‌کردند سرشان کلاه رفته است. این ماجرا باعث شد تا صنعت فناوری به اهمیت شفافیت با مشتریان و تعامل صادقانه با آن‌ها به‌ویژه درمورد نقص‌های فنی محصولات پی ببرد.

از سوی دیگر، رضایت مشتری و وفاداری به برند به دغدغه‌ی اصلی شرکت‌های فناوری تبدیل شد. اینتل ابتدا فقط پردازنده‌های کاربرانی را تعویض می‌کرد که می‌توانستند ثابت کنند این باگ در کارهایشان اختلال ایجاد کرده است؛ اما پس از واکنش‌های گسترده، اینتل پذیرفت تمام پردازنده‌های باگ‌دار را به‌طور رایگان تعویض کند.

باگ پنتیوم همچنین نشان داد گاهی یک اشتباه به‌ظاهر کوچک اگر به‌خوبی مدیریت نشود، می‌تواند اعتبار یک برند را خدشه‌دار و هزینه‌های گزافی به آن تحمیل کند. شرکت‌های فناوری آموختند که صرف هزینه در بخش کنترل کیفیت و اقدامات پیشگیرانه معمولا هزینه‌ی کمتری نسبت‌به فراخوانی محصول و تلاش برای بازیابی اعتبار برند دارد.