21.04.2017

Сигнал 11 Під Час Компіляції Ядра

Переклад зроблено з веб-сторінки http://bitwizard.nl/sig11/, що є власністю BitWizard B.V.

BitWizard B.V.

Цей розділ описує те, що можливі причини для ефекту, який турбує багато людей останнім часом. А саме, що лінукс (*) – ядро (або будь-який інший великий пакет з цього питання) компілювати аварії з “сигналом 11”. Причиною може бути програмне забезпечення, або (швидше за все) обладнання. Читайте далі, щоб дізнатися більше.

(*) Звичайно, ніщо не є Linux специфічні. Якщо ваше обладнання листкові, Linux, Windows 3.1, FreeBSD, Windows NT і NextStep буде все аварії.

Запитання та відповіді про сигнал 11 (Sig11)

ЗАПИТАННЯ
Сигнал 11, що це значить?

ВІДПОВІДЬ
Сигнал 11, або офіційно відомий як “помилка сегментації”, означає, що програма звертається до комірки пам’яті, яка не була призначена. Це, як правило, помилка в програмі. Так що, якщо ви пишете свою власну програму, це найбільш ймовірна причина. Проте, цю сторінку запитань і відповідей буде зосереджено на можливостях, крім цього.

ЗАПИТАННЯ
Моя компіляція
(ядра) не спрацьовує з

   gcc: Internal compiler error: program cc1 got fatal signal 11

Що трапилося з компілятором? Яка версія компілятора мені потрібно зробити? Чи є щось не так з ядром?

ВІДПОВІДЬ
Швидше за все, немає нічого поганого в вашій установці, компілятором або ядра. Це дуже ймовірно, що щось робити з вашим обладнанням. Є безліч підсистем, які можуть бути неправильно, і існує безліч способів, щоб виправити це. Читайте далі, і ви дізнаєтеся більше. Є два винятки з цього “правила”. Ви могли б бути розряджений на віртуальній пам’яті, або ви могли б бути установка Red Hat 5.x, 6.x або 7.x. Існує більше про це ближче до кінця.

ЗАПИТАННЯ
Добре це може бути програмне забезпечення, Як я знаю напевно?

ВІДПОВІДЬ

По-перше дозволяє переконатися, що це обладнання, яке викликає у вас проблеми. Коли “make” зупиняється, просто наберіть “make” знову. Якщо він збирає ще кілька файлів перед зупинкою, воно повинно бути апаратне забезпечення, яке заподіює вам неприємності. Якщо він відразу ж знову зупиняється (тобто сканує кілька каталогів з “нічого не буде зроблено для хххх” до бомбардування в один і той же місце), спробуйте

   dd if=/dev/HARD_DISK of=/dev/null bs=1024k count=MEGS

Зміна HARD_DISK на “hda” на ім’я вашого жорсткого диска (наприклад, hda чи sda. Або використовувати “df”.). Зміна MEGS кількості мегабайт оперативної пам’яті, що у вас є. Це призведе до того, що перші кілька мегабайт вашого жорсткого диска для читання з диска, змушуючи вихідні файли C і gcc бінарник перечитувати з диска в наступний раз, коли ви запускаєте його. Тепер надрукуйте зробити ще раз. Якщо він все ще зупиняється в тому ж місці, я починаю шукати відповіді на запитання, якщо ви читаєте правильний запитання та відповіді, як це починає виглядати як проблема програмного забезпечення після всіх…. Заглянути в “інші можливості” питання….. “Якщо без цього” “команда компілятор продовжує зупиняючись на тому ж самому місці, але рухається в інше місце після використання “dd” ви, безумовно, є диск->оперативна пам’ять проблеми.

ЗАПИТАННЯ
Що це означає? Ви впевнені, що це апаратна проблема?

ВІДПОВІДЬ
Ну, компілятор доступ до пам’яті за межами її пам’яті. Якщо це відбувається на роботі обладнання, це помилка програмування всередині компілятора. Ось чому він говорить, що “внутрішня помилка компілятора”. Однак, коли обладнання іноді підкидає трохи, gcc використовує так багато покажчиків, що це, ймовірно, в кінцевому підсумку доступ до щось поза ним адресації діапазону. (Випадкові адреси в основному за межами діапазону адресації, так як, навіть якщо ваш основний пам’яті може бути значна частина 4G в даний час, як правило, тільки невелика частина перетворюється в якийсь один процес. 🙂 Здається, що в наші дні, кожен з “сигналом 11“. Проблема отримує спрямована на цю сторінку. Якщо ви розробляєте власне програмне забезпечення або мати програмне забезпечення, яке не було налагодженої цілком достатньо, “Сигнал 11” (або помилка сегментації) як і раніше дуже сильний натяк на те, що є щось не так з програмою. Тільки тоді, коли програма, як “gcc”, яка працює майже всі інші аварії на наборі даних (наприклад, в Linux-ядрі), що також добре відпрацьованим, то стає натяк, що є щось трапилося з вашим обладнанням. Якщо який-небудь компонент програмного забезпечення як драйвер апаратного в системі порушуються, це може викликати симптоми, які дуже близькі до апаратного збою. Однак, коли водій несправний, більш імовірно, щоб викликати серйозні проблеми всередині ядра, ніж просто викликає компілятор врізатися.

ЗАПИТАННЯ
Добре. У мене може бути проблема апаратних засобів, що це?

ВІДПОВІДЬ
Якщо це трапляється, обладнання може бути:

• Основна пам’ять. Ваша основна пам’ять може отримувати випадкові трохи неправильно. Якщо це відбувається на “записи”, ви не побачите ніяких помилок парності. Є кілька способів це виправити:

ο Швидкість пам’яті може бути занадто повільною. Збільшення числа станів очікування в BIOS.
Це може бути викликано можливістю AMIBIOS автонастройки: це може знати тільки про 486 працює Шифрування до 80 МГц, в той час як ви в даний час купити 100 МГц версії. – Пат В.
ο
Швидкість пам’яті може бути занадто повільним. Отримати швидше DRAM SIMM. Наприклад поточні материнські плати ASUS вимагають 60 нс DRAM, якщо у вас є 100 або процесор 133 МГц (подивіться в інструкції до материнської плати). Я чув повідомлення, що 70 нс також працює, проблеми надійності, як випадкові sig11 належимо до можливостей …. (я б не ризикувати) – Ендрю Ескілсон (mpt95aes@pt.hk-r.se)
ο Можна подумати, що ви можете запустити ваш 100 МГц SDRAM на 100 МГц . Неправильно! прочитати http://www.bitwizard.nl/sig11/sdram чому я думаю, що це так. Вам потрібно принаймні, одну швидкість класу швидше, ніж швидкість вони розраховані на.
ο Існує поганий чіп на одному з SIMM. Якщо у вас є більш ніж 1 банк пам’яті, ви можете бути в змозі витягнути модулі SIMM і подивитися, якщо проблема зникне. Будьте обережні STATIC!!!
ο Ми обробили важко тут минулого тижня. Виявилося, що всі 4 16 МБ SIMM були розбиті в тому, що вони впали трохи приблизно раз на годину. Цього було достатньо, щоб розбити машину приблизно через день, або збій компіляції ядра приблизно через годину. Новий набір SIMM відмінно працює. Минуло багато часу, щоб діагностувати цю, тому що всі 4 з SIMM були порушені однаково, тому, залишаючи половину пам’яті з не змінити стан речей.
Марк Кеттнер (kettner@cat.et.tudelft.nl) повідомляє, що його система була здатна працювати мій тест пам’яті для 2300 раз безвідмовно, але потім виявив близько 10 помилок. Потім він продовжував виявляти не помилок для кількох сотень прогонів знову….. В разі працює компілює ядро ​​було набагато ефективнішим способом виявлення стану системи (в найбільш стабільною конфігурації система може компілювати близько 14 ядер, перш ніж вояки). Його рішення було “торгувати” старій пам’яті для так званого “відновлення пам’яті”. Крамар потім “випробування” в їх тестері пам’яті, який OK пам’яті. Потім він отримав хорошу знижку на новий 🙂 пам’яті.
ο
Здається, що деякі 30-72 контактних перетворювачі можуть привести до помилок пам’яті. (Подивіться, як старий цей запис Хто пам’ятає 30-пін модулі SIMM Однак всі ці речі тримати ідеально для SIMM? <-> перетворювачів DIMM або Сокет370 <-> слот 1 нейтралізатори) (Це не доведено 4 SIMM в перетворювачі зіпсувалися, або якщо перетворювач SIMM був з вини SIMMS були відмінно функціонує протягом багатьох років, перш ніж вони були переміщені в конвертер….) – Нареш Шарма (n.sharma@is.twi.tudelft.nl), Пол Гортмакер (paul.gortmaker@anu.edu.au) додає, що перетворювачі SIMM повинні мати принаймні 4 розв’язують конденсаторів, щоб зберегти електроживлення SIMM чистою.
ο Якщо оновлена ​​DRAM не функціонують належним чином, DRAM буде поступово втрачати свою інформацію. Деякі з них (486) материнські плати перестають правильно освіжаючі при включенні “прихованого поновлення”. Там, здається, програма під назвою “dram”, навколо якого також може зіпсувати ваші оновлення, щоб викликати проблеми sig11. – Хенк Барт (hank@pswin.chi.il.us), Рон Тапіа (tapia@nmia.com)
ο Число станів очікування може бути занадто низьким. Збільшення числа станів очікування в BIOS для виправлення. Плата Intel Endeavour не дозволяє збільшувати пам’ять стану очікування. Це нібито може бути виправлено шляхом перепрошивки MR BIOS на материнській платі. – Девід Холс (david.halls@cl.cam.ac.uk)
ο Деякі модулі пам’яті просто не люблять працювати разом з іншими. Окремо вони обидва працюють разом, вони не роблять. Це, швидше за все, відбудеться, якщо ви змішуєте різні марки і розміри. Офіційно, якщо ви будете дотримуватися специфікацій для всіх модулів, вона завжди працює. Неофіційно ви іноді зіткнетеся з проблемами.

Кеш-пам’ять. Ваш кеш-пам’ять може отримувати випадкові трохи неправильно. Кеші, як правило, не обладнані парності. Ви можете діагностувати, що це так, відключивши кеш в BIOS. Якщо проблема не зникне це, ймовірно, кеш. Є кілька способів це виправити:

ο Швидкість кеш-пам’яті може бути занадто повільною. Збільшення числа станів очікування в BIOS.
ο Швидкість кеш-пам’яті може бути занадто повільною. Отримати швидкі чіпи SRAM.
ο Існує поганий чіп в кеші. Малоймовірно, що ви можете змінити фішки так само легко, як і з SIMM. Будьте обережні STATIC!!! – Джозеф Бароне (barone@mntr02.psf.ge.com)
ο Кеш може бути встановлений на “зворотної записи” в той час як є помилка в зворотному записи реалізації вашого чіпсета. Плата, де це сталося, був “MV020 486VL3H” (з 20М RAM) – Скотт Брамбах (scottb@borris.beachnet.com) (адреса електронної пошти не працює Скотт: Отримати на мене з дійсною адресою повернення.)
ο Материнська плата може знадобитися перемичками для перемикання між кешем на паличку і старомодний кеш падіння чіпа. (материнські плати JP16 на Rev 2.4 ASUS P/I-P55TP4XE)

Дискові перенесення. Блок приходить з диска може спричинити випадкову бітову помилку.

ο Якщо у вас є ця проблема, ви, швидше за все, щоб зробити команду “dd” на “move” проблема від одного місця до іншого….
ο Деякі IDE жорсткі диски не можуть впоратися з опцією “irq_unmasking”. Це може показати тільки під навантаженням. І це може показати, як sig11.
ο Деякі розстановки не можуть впоратися з DMA в деяких конфігураціях. Маріо Модер повідомляє, що його система, нарешті, почала працювати правильно після включення 32-бітного-IO як для його жорсткого диска і його компакт-дисків. – Маріо Модер (clay-man@freenet.de)
ο Чи є у вас kalok 31xx? Киньте його в сміття. (Або продати його користувачеві DOS оновлення: чи не чув про KALOK протягом багатьох років вони, ймовірно, бюст накопичувачі також не працюють з W95, до речі…)
ο SCSI? Припинення? Коротка шина може ще працювати (ненадійно, що є) з поганим припиненням. Довга шина може отримати помилки в будь-якому випадку. Ви можете включити паритет на хості і DISK?

• Сам процесор. Деякі партії процесорів мають набагато більш високий відсоток з них, які відбуваються, щоб бути “поганим”. Кілька років тому: оригінальний Intel-Pentium-120-х. Кілька років тому AMD K6/2-300 (1998, вироблений протягом декількох тижнів 34 через 39!). А останнім часом AMD K6/2-450 років. Деякі люди можуть вирішити, що сказати 400 МГц є прийнятним для них, проте, якщо це виявляється проблема, ви маєте право на новий процесор. Ідіть і обміняти його там, де ви його купили. (Забудьте про тих P120, це не має сенсу…;-) – Гійом Коттенсо (gcottenc@ens.insa-rennes.fr) і Марк Кіган (keegan@mx.qc.ca)

Сам процесор. Деякі партії процесорів K6 просто дизайн помилка. Читайте http://www.multimania.com/poulot/k6bug.html, а потім переконайтеся, що ви отримаєте ваш K6 обмін. – Rongen (rongen@istar.ca).

• Розгін. Процесори Cyrix P-166 не працюють на частоті 133 МГц, а не на 166. Це повинно бути логічно хлопців в Cyrix, але ніхто інший. Ви розганяти їх, якщо запустити їх на 166 МГц….. (Примітка: деякі з цих запитань і відповідей досить старі. Тепер AMD почав робити те ж саме: запустити XP1800 за адресою 1533 МГц)

Розгін. Деякі виробники (або приватні особи) вважають, що можна розігнати кілька процесорів. Деякі з них можуть працювати інші не роблять. Ви можете спробувати відключити турбо (зверніть увагу, що більшість материнських плат Pentium більше не підтримують режим не-турбо) і подивитися, якщо проблема зникне. Перевірте швидкість роботи процесора в порівнянні (надрукований на ній, обережно зніміть вентилятор в разі необхідності) з тим, що говорять парашутисти материнської плати або настройки BIOS…. Здається, що навіть Intel може робити помилки в цій галузі. Тепер у мене є кілька надійних звітів, що офіційний Пентіум б sig11 при номінальній швидкості, але не на більш низькій швидкості. Що стосується деяких швидкостей плата тільки підкреслив БІЛЬШЕ для повільній швидкості процесора (120 МГц-> материнська плата працює на 60 МГц, 100 МГц-> материнська плата працює на частоті 66 МГц), я думаю, що це малоймовірно, що це не має нічого спільного з материнською платою. Крім того новий процесор 120 МГц тепер функціонує правильно. – Семуеля РамаКо (sramac@vnet.ibm.com). Це не є унікальним для Intel або будь-який з її конкурентів.

Розгін. В даний час, швидкість процесора, розсіює потужність і т.д. і т.д., все так близько до “краю”, що кожні зараз, і тоді надійні корпораціям, такі як Intel, доведеться вдатися до хитрощів, які оверклокери використовують для підвищення продуктивності. Результати також можуть бути порівняні: Випадково, звісно, ​​sig11 і т.д.

Температура процесора. Висока частота процесора може перегрітися без правильного радіатора. Це також може бути викликано несправним вентилятором. (Мій особистий “486 є вентилятор, який займає кілька хвилин, щоб дістатися до швидкості. Це, ймовірно, ніколи не буде насправді не тому, що це тепер списаний :-). Процесор може стати нестійким, якщо “штовхнув” при компіляції ядра. Ця проблема стає ще гірше, якщо відключити “HALT” в командному рядку LILO. Linux намагається живити вниз CPU, виконавши “HALT” інструкції, коли система знаходиться в режимі очікування. Це зберігає силу, і тому температура процесора знижується, коли система знаходиться в режимі очікування. Ви, отже, не могли б помітити цю проблему, коли просто редагування, і це може тільки поверхню після декількох годин ресурсномістких робочих місць, коли температура навколишнього середовища висока. Якщо у вас є Pentium з FDIV помилка, рекомендується торгувати на на Intel. Вони будуть посилати вам нову, попередньо сконфігурованих з офіційним Intel затвердженої ВЕНТИЛЯТОР. Також відзначимо, що більшість нормальних клеїть дуже погані теплові провідники. Існує спеціальний тепловий клей доступний, який повинен бути використаний, коли вентилятор повинен бути приклеєний до процесора. – Арно Гріффіоен (arno@ixe.net), – У. Пол Мілс (wpmills@midusa.net) – Alan Wind (wind@imada.ou.dk)

Intel говорить, що допустима температура коливається для поза вашого процесора є:
від 0 до +85 С: Intel486 SX, Intel486 DX, IntelDX2, IntelDX4 процесор
від 0 до +95 C: IntelDX2, процесори IntelDX4 OverDrive®
від 0 до +80 С: 60 МГц Процесор Pentium®
від 0 до +70 С: від 66 до 166 МГц процесора Pentium
Для отримання інформації про те, як виміряти і деяке підтвердження того, що я говорю тут, див.: http://pentium.intel.com/procs/support/faqs/iarcfaq.htm (особливо питання 5, 6 і 12. Документ стає трохи застарілим, але все ще дуже точний. здається, питання рухатися навколо трохи кожен зараз і потім, а також.) (Intel тепер перемістив файл. Я не міг знайти нову. Хтось, хто може мені точку на нове місце???)

• Напруга процесора. Деякі материнські плати дозволяють вибирати напруга живлення процесора. Деякі материнські плати погано документують установки перемичок, які керують цим. Здається, що процесор 5 В може ще працювати більшу частину часу на 3,3 вольт….. – Карл Хейс (krheyes@comp.brad.ac.uk)

ОЗУ напруга. Схоже, що виробники готуються до 3,3 В оперативної пам’яті в даний час. Більшість пам’яті тепер 3,3 В. (Але будьте обережні, якщо у вас є рада, здатні установки напруги RAM: 3,3 В RAM зламаються на 5 В…..) (Заслухавши трохи про це, я думаю, що вимикач повинен бути автоматичним.)

Перевантаження локальної шини. На 25 МГц ви дозволено мати 3 VesaLocalBus (VLB) карти, на 33 МГц тільки два, на 40 МГц тільки один і вгадати, що на 50 МГц ЖОДНИХ! (Тобто вам дозволено запускати систему з локальною шиною 50 МГц, але тоді ви не можете використовувати будь-які карти VLB). Деякі системи починають діяти листкове при перевантаженні VLB. Навіть якщо ваш VLB не переобтяжена (за межі значень, зазначених вище), система може втратити кілька наносекунд краю шляхом додавання додаткової карти VLB, так що вам може знадобитися додати кеш стан очікування або щось після того, як ви додали нова VLB карта…. – Річард Постгейт (postgate@cafe.net)

Управління енергією. Деякі ноутбуки (і в даний час також “зелений” ПК) мають функції управління живленням. Це може заважати Linux. Одна функція може зберегти образ пам’яті для HD і відновлення пам’яті при натисканні клавіші. Це звучить як весело, але драйвери пристроїв Linux не слід очікувати, що обладнання було відключено від двох доступів. Деякі з них можуть відновити, а інші ні. Спробуйте відключити його, або включення “Підтримка APM” в ядрі. – Елізабет Ейер (eca23@cam.ac.uk)

Розгойдування пилу. Деяка пил може провести трохи і створити слабку короткий. Це може збільшити ємності десь, і погіршити тимчасові характеристики. Це може перешкоджати тепловий потік, і привести до перегріву компонентів. Це може навіть короткий з’єднання перемички! Я рекомендую, щоб кожен рік або близько того, це гарна ідея, щоб відкрити свій комп’ютер, і вакуум всередині. Порада: ті, бавовняні на паличці рюшечки допомагають підштовхуючи пил з важкодоступних місць… – Крейг Грем (c_graham@hinge.mistral.co.uk). Хтось сказав мені: якщо ви можете використовувати стиснене повітря, щоб підірвати речі замість пилососа. Переважно робити це зовні.

Сам процесор. Деякі люди повідомляють, що вони не знайшли нічого звинувачувати, крім процесора. Це також могло б бути несумісність між процесором і материнською платою. Хвиля повідомлень про процесорах Intel пройшло (лютий 97 року). Нова хвиля повідомлень приходить в тому, що звалюють Cyrix/IBM 6×86 процесорів. Незважаючи на те, що дійсно може бути процесор, він також може бути, що ваша материнська плата не сумісна з вашим процесором. Принаймні, я бачив материнську плату вручну нагадуйте, що він не сумісний з більш старими 6×86 років. Мій власний досвід показує, що ці пристрої не погано на всіх, і на компіляції ядра я протестований з P166 + еквівалентним з P155 (в 1,3 рази швидше, ніж P120).
Отвір пам’яті. Багато сучасні материнські плати дозволяють використовувати старі відеокарти ISA з одним або двома мегабайтами лінійного буфера кадру. Для досягнення цієї мети, вони повинні карту з пам’яті трохи нижче 16 Мб. Ніхто насправді ніколи не використовував цю функцію, але якщо ви дозволите отвір пам’яті (або підтримки LFB в деяких BIOS) на, ваша машина буде, безумовно, буде відшаровуватися….. – Пол Конноллі (pconnolly@macdux.com.au)

X і AMD несумісність. Існує проблема з купою сучасних чіпів AMD, які не обробляють деякі операції настільки ж добре, як вони повинні. Якщо у вас є AMD і X11 часто завершує роботу з “сигналом 11 спійманої”, то ви можете бути жертвою цього питання. Спробуйте завантажитися з “mem=nopentium”. – Метью Біл (mixonic@synitech.com).

Мікрокод. Особливо на багатопроцесорних системах процесори можуть потребувати оновлення. З поділом катастрофи Pentium, Intel має свої поля процесорів модернізовані! Процесор може бути врізався кілька версій за спеціальною інструкцією від BIOS. Ці оновлення, як правило, приходять з BIOS, тому переконайтеся, що ви використовуєте останній BIOS, особливо якщо у вас є система SMP. – Джеффрі Фредл (адреса ел. пошти не розголошується).
ЗАПИТАННЯ
Проблеми RAM синхронізації? Я повозився з настройками биоса більше, ніж місяць тому. Я зібрав численні ядра в той же час і нічого не пішло не так. Це не може бути часу ОЗУ. Вірно?
ВІДПОВІДЬ
Неправильно. Як ви думаєте, що виробники RAM є машина, яка робить 60ns баран і ще одне, що робить 70 нс RAM? Звичайно, ні! Вони роблять купу, а потім перевірити їх. Деякі відповідають специфікації на 60 нс, а інші ні. Це можуть бути 61 нс, якщо виробник повинен поставити ряд до нього. У цьому випадку цілком ймовірно, що вона працює на вашому комп’ютері, якщо, наприклад, температура нижче 40 градусів за Цельсієм (чіпи стають повільніше, коли температура піднімається. Саме тому деякі суперкомп’ютери потрібно стільки охолодження).
Однак “прихід літа” або довга робота компіляції може підштовхнути температуру всередині вашого комп’ютера через “межа”. – Філіп Тройн (ptroin@compass-da.com)

ЗАПИТАННЯ

Я був обманутий в не купувати пам’ять ECC, тому що він був трохи дешевше. Я відчуваю себе дурнем. Я б купив дорожчу пам’ять ECC. Вірно?

ВІДПОВІДЬ
Купуючи дорожчу пам’ять ECC і материнські плати захищає вас від певного типу помилок: ті, які відбуваються у випадковому порядку, пропускаючи альфа-частинки.
Оскільки більшість людей може відтворити “сигнал 11” проблеми протягом півгодини за допомогою “gcc”, але не може відтворити їх при тестуванні пам’яті протягом кількох годин поспіль, що доводить мені, що це не просто випадкова альфа-частинки гортати небагато. Це було б отримати помітили тест пам’яті теж. Це означає, що щось ще відбувається.

У мене склалося враження, що більшість проблем sig11 викликані помилками синхронізації на CPU <-> кеш <-> шлях пам’яті. ECC на основний пам’яті не допоможе вам в цьому випадку.

Коли ви повинні купити ECC? а) Коли ви відчуваєте, що вам потрібно. б) Якщо у вас є БАГАТО оперативної пам’яті. (Чому не відсічення номер? Оскільки зміни відрізні згодом, так само, як “БАГАТО”). Деякі люди відчувають себе дуже сильним про всі, використовуючи пам’ять ECC. Я маю на увазі їх урезонити “а)”.

ЗАПИТАННЯ
Проблеми з пам’яттю? Мій BIOS перевіряє мою пам’ять і каже мені, що його добре. У мене є ця фантазія програма DOS, яка говорить мені, що моя пам’ять в порядку. Не може бути право пам’яті?
ВІДПОВІДЬ
Неправильно. Тест пам’яті в BIOS абсолютно марно. Це може бути навіть іноді OK більше пам’яті, ніж насправді є в наявності, не кажучи вже про тест чи є це добре чи ні.
Один мій знайомий мав звичай мати 640K ПК (так, це було дуже давно), який мав один 64 Кбіт чіп замість чіпа 256 Кбіт в другому 256k банку. Це означає, що він фактично мав 320K робочу пам’ять. Іноді BIOS буде перевіряти 384k як “OK”. У всякому разі, тільки деякі додатки не зможуть. Це було дуже важко діагностувати фактичну проблему…

Більшість проблем пам’яті виникають лише при особливих обставинах. Ці обставини навряд чи коли-небудь знав. gcc здається здійснювати їх. Деякі тести пам’яті, особливо тести пам’яті BIOS, не мають. Я більше не працюю над створенням дискети з Linux ядром і хорошим тестером пам’яті на ньому. Забудьте про підслуховування мені про це……Причина полягає в тому, що тест пам’яті змушує процесор виконати всього кілька інструкцій, а також шаблони доступу до пам’яті, як правило, дуже регулярно. У цих умовах тільки дуже невелика частина спогадів ламається. Якщо ви вивчаєте електротехніки і зацікавлені в тестуванні пам’яті, майстри тезу можна було б зрозуміти, що відбувається. Є виробники комп’ютерів, які хотіли б спонсорувати такий проект з деякими апаратними засобами, що клієнти стверджують, щоб бути ненадійними, але не призведе до збою виробничих випробувань……

ЗАПИТАННЯ
Чи трапляється, тільки тоді, коли я компілює ядро?
ВІДПОВІДЬ
Ні. Там немає ніякого способу, ваше обладнання може знати, що ви компілюєте ядро. Просто так вийшло, що ядро компіляції дуже жорстко на вашому обладнанні, так що це просто трапляється багато, коли ви компілюєте ядро. Компіляція інші великі пакети, такі як gcc або glibc також часто викликають в sig11.
• Люди бачили “випадкові” збої, наприклад при установці за допомогою сценарію установки Slackware…. – dhn@pluto.njcc.com
Інші отримати “загальну помилки захисту” від ядра (з crashdump). Вони, як правило, в /var/adm/messages. – fox@graphics.cs.nyu.edu
Деякі бачать bzip2crash з “сигналом 11” або “внутрішньої несправністю затвердження” (#1007). Bzip2 досить добре перевірений, так що, якщо він виходить з ладу, то, швидше за все, не помилка в bzip2. – Джуліан Сьюард (jseward@acm.org)
ПИТАННЯ
Ніщо не виходить з ладу на NT, Windows 95, 98, Milennium або XP. Це повинно бути щось Linux специфічні.
ВІДПОВІДЬ
Перш за все, Linux підкреслює ваше обладнання більш ніж все перераховане вище. Деякі операційні системи, такі як ті, Microsoft названих вище аварії непередбачуваним чином в будь-якому випадку. Ніхто не збирається називати Microsoft і сказати: “Гей, моя вікна ящик розбився сьогодні”. Якщо ви в будь-якому випадку, вони скажуть вам, що ви, користувач зробив помилку (див. інтерв’ю з Біллом Гейтсом у німецькому журналі….) і що, так як він працює в даний час, ви повинні зіткнутися.
Ці операційні системи також кілька більш “передбачуваною”, ніж Linux. Це означає, що Excel завжди може бути завантажений в тій же самій області пам’яті. Тому при виникненні бітових помилок, завжди перед веде, що отримує його. Excel буде врізатися. Або головує розіб’є іншу програму. У всякому разі, це буде здаватися один додаток, яке виходить з ладу, і не має відношення до пам’яті.

Те, що я впевнений в тому, що чисто встановлена ​​система Linux повинна мати можливість скомпілювати ядро ​​без будь-яких помилок. немає, звичайно, не сигнал 11 з них. (** Виняток: Red Hat 5.0 з процесором Cyrix. Див. в інших місцях. **)
Насправді Linux і gcc стрес ваше обладнання більш ніж інші операційні системи. Якщо вам потрібна не Linux штуковина, яка підкреслює ваше обладнання до точки збою, ви можете спробувати Winstone. – Джонатан Брайт (bright@informix.com)
ЗАПИТАННЯ
Чи завжди це сигнал 11?
ВІДПОВІДЬ
Ні. Інші сигнали, такі як чотири, шість і сім також іноді відбуваються. Сигнал 11 є найбільш поширеним, хоча.
Поки пам’ять пошкоджені, все може трапитися. Я б очікувати погані бінарні файли відбуваються набагато частіше, ніж вони насправді. У всякому разі, здається, що шанси сильно зміщені в стороні gcc отримання сигналу 11. бачив також:

  • free_one_pmd: bad directory entry 00000008
  • EXT2-fs warning (device 08:14): ext_2_free_blocks bit already cleared for block 127916
  • Internal error: bad swap device
  • Trying to free nonexistent swap-page
  • kfree of non-kmalloced memory …
  • scsi0: REQ before WAIT DISCONNECT IID
  • Unable to handle kernel NULL pointer dereference at virtual address c0000004
  • put_page: page already exists 00000046
    invalid operand: 0000
  • Whee.. inode changed from under us. Tell Linus
  • crc error — System halted (During the uncompress of the Linux kernel)
  • Segmentation fault
  • “unable to resolve symbol”
  • make [1]: *** [sub_dirs] Error 139
    make: *** [linuxsubdirs] Error 1
  • The X Window system can terminate with a “caught signal xx”

Перші з них є випадками, коли ядро “підозрюваний” ядро-програмування помилок, що насправді викликані поганою пам’яттю. Останні кілька пункт прикладних програм, які в кінцевому підсумку з неприємності.

– С.Г. де Марініс (trance@interseg.it)
– Дірк Начтманн (nachtman@kogs.informatik.uni-hamburg.de)

ЗАПИТАННЯ
Що мені робити?

ВІДПОВІДЬ
Ось деякі речі, щоб спробувати, якщо ви хочете дізнатися, що це неправильно… Примітка: деякі з них будуть істотно уповільнити роботу комп’ютера. Ці речі призначені, щоб отримати ваш комп’ютер, щоб функціонувати належним чином і дозволяють звузити те, що трапилося з ним. З цією інформацією ви можете, наприклад, спробувати отримати несправний компонент замінений на постачальника.

  • Перемичка плати для нижнього центрального процесора і швидкості шини.
  • Заходимо в BIOS і сказати йому “Load BIOS defaults”. Переконайтеся, що ви заздалегідь записати установки дисковода вниз.
  • Вимкніть кеш (BIOS) (бо витягнути його, якщо він знаходиться на “стік”).
  • завантаження ядра з “linux mem=4M” (відключає пам’ять вище 4 Мб).
  • Спробуйте виймаючи половину пам’яті. Спробуйте обидві половинки в свою чергу.
  • Попрацюйте з настройками поновлення (BIOS)
  • Спробуйте пам’ять запозичення від кого-то другого. Переважно, це повинно бути пам’ять, яка працює Linux безвідмовно в іншій машині… (Silicon Graphics Indy машини також хороші цілі для запозичують пам’яті від)
  • Якщо ви хочете перевірити, якщо рішення дійсно працює спробуйте наступний сценарій:
       #!/bin/sh
       #set -x
       t=1
       while [ -f log.$t ] 
         do
         t=`expr $t + 1`
       done
    
       while true
         do
         make clean
         make -k bzImage > log.cur 2>&1
         mv log.cur log.$t
         t=`expr $t + 1`
       done
    
  • Всі отримані балки повинні бути однаковими (тобто той же розмір, і той же вміст). Кожен збірки ядра займає близько 4 хвилин на 1 ГГц Athlon з 512 Мб оперативної пам’яті. (І близько 3 місяців на 386 з 4 Mб :-).
  • Ще один спосіб перевірити, якщо поточна настройка є стабільною може бути для запуску “md5sum” з файлами різних розмірів (dd if=/dev/random of=testfile bs=1024k count=). Якщо ви використовуєте файл двічі розмір оперативної пам’яті, ви будете здійснювати ваш диск. Якщо використовувати файл 4 до 10 Мб менше, ніж обсяг оперативної пам’яті, ви будете тренувати RAM/CPU.
    Якщо вловлює цей метод всі можливі проблеми, тим не менш, є невизначеним. Gcc виконує багато різних інструкцій в різних порядках, і md5sum може просто не потрапив в правильну послідовність інструкцій, gcc робить. Але якщо md5sum призводить до помилок, це може зробити це швидше, ніж компіляції ядра. – Роб Людвік(rob@no-spam)

Найважча частина в тому, що більшість людей буде в змозі зробити все перераховане вище, крім запозичення пам’яті від когось іншого, і це не робить різниці. Це підвищує ймовірність того, що він дійсно є ОЗУ. ОЗУ використовується як один з найдорожчих частин комп’ютера, так що ви воліли б не прийти до такого висновку, але, вибачте, я отримую багато реакцій, які врешті-решт опиняються в ОЗУ. Однак не впадайте у відчай тільки поки: ваша пам’ять не може бути повністю витрачені даремно: ви завжди можете спробувати торгувати протягом різної або більше оперативної пам’яті.

ЗАПИТАННЯ
У мене були ОЗУ, випробувані в тестері ОЗУ, і вони в порядку. Не може бути право ОЗУ?

ВІДПОВІДЬ
Неправильно. Здається, що помилки, які в даний час відбувається в баранах не виявляється випробувачі ОЗУ. Може бути, що ваша материнська плата має доступ баранів в сумнівних відносинах чи інакше псуючи ОЗУ, поки він знаходиться у вашому комп’ютері. Перевага полягає в тому, що ви можете продати ОЗУ для тих, хто все ще є впевненість в своєму ОЗУ-тестері ……

ЗАПИТАННЯ
Які інші апаратні засоби може бути проблема?

ВІДПОВІДЬ
Ну, будь-яка апаратна проблема в вашому комп’ютері. Але речі, які легко перевірити, повинні бути перевірені в першу чергу. Так, наприклад, всі ваші карти повинні бути правильно вставлений в материнську плату.

ЗАПИТАННЯ
Чому Red Hat встановити бомбардування на мене?

ВІДПОВІДЬ
Red Hat 5.x, 6.x і 7.x установка має проблеми на деяких машинах. Спробуйте запустити установку з тільки 32M. Зазвичай це може бути зроблено з = 32М ними пам’яттю як параметр завантаження.

Це може бути, що для читання помилок на компакт-диску. Установник обробляє це менш ніж досконалий….. Переконайтеся, що ваш CD бездоганний! Створюється враження, що програма установки бомби на маргінальних компакт-дисків!

Люди повідомляють, і я бачив на власні очі, що Red Hat встановлює помилитеся (аварії з сигналом 7 або сигнал 11) на машинах, які в порядку. Моя машина була і до сих пір є 100% надійним (насправді машина, я відчув це на, до теперішнього часу надійно мертвий). Люди отримують в біду, протерши старе “працює просто відмінно” розподіл, а потім бажаючи встановити більш пізній розподіл Red Hat. Повертаючись не тоді вже не варіант, тому що повертаючись до 5.x також призводить до того ж “збої при установці”.

Патрік Хейлі (haleyp@austin.rr.com) повідомляє, що він перепробував все конфігурації пам’яті до 96 МБ (32 і 64) і виявив, що тільки тоді, коли він встановлений 96 МБ, установка буде працювати. Це також узгоджується з моїм власним досвідом (від Red Hat встановлює невдачу): Я спробував встановити на 32M машині.

НОВЕ: здається, що це може бути пов’язано з проблемою ядра. Ядро може (temporarliy) запустити низько на пам’яті і вбити поточний процес. Виправлення Хуберт Мантель (mantel@suse.de) знаходиться за адресою: http://juanjox.linuxhq.com/patch/20-p0459.html.

Якщо це дійсно так, то спробуйте переключитися на другу віртуальну консоль (Ctrl-Alt-F2) і типу “синхронізації” там кожні кілька секунд. Це зменшує споживання пам’яті HARDDISK-буфера… Я був би дуже вдячний почути від вас, якщо ви бачили Red Hat встановити аварії два або більше разів поспіль, а потім була в змозі закінчити установку за допомогою цього трюку!!!

Що ви робите, щоб обійти цю проблему?…

  • Скористайтеся SuSE. Це краще: не ламається під час інсталяції. (Більше того, це фактично є кращим рішенням. 😉
  • Може бути, ви працюєте в зіпсованих блоків на компакт-диску. Це може бути диск-залежними. Якщо це так, спробуйте зробити копію компакт-диска в інший диск. Спробуйте запозичення чужої копії Red Hat.
  • Спробуйте настройки ГІГАБАЙТ свопу. У мене є два незалежних доповіді, які повідомляють, що вони отримали через з концертом свопу. Будь ласка, повідомте мені, якщо це допомагає!
  • Змінити “налаштування” для жорсткого диска. Зміна налаштувань з “LBA” на “NORMAL” у bios допомагає, по крайней мере, одну людину. Якщо ви спробуєте це, я буду дуже вдячний, якщо ви надішлете мені електронного листа: я хотів би почути від вас, якщо це допомагає чи ні. (І то, що ви точно змінили, щоб змусити його працювати)
  • Я отримав свою машину, щоб встановити, встановивши мінімальну базову систему, а потім додавання пакетів у встановленій системі.
  • Хтось припустив, що машина може бути через брак пам’яті, коли це станеться. Спробуйте маючи розділ підкачки готовий. Крім того, програма установки може бути підготовленадля обробки низьких mem ситуацій, але недооцінює ситуацію. Наприклад, він може завантажити RAMDISK, залишивши тільки 1M вільної оперативної пам’яті, а потім намагається завантажити додаток 2М. Так що якщо у вас є 16M оперативної пам’яті, завантаження з mem = 14M ними пам’яті може реально допомогти, як “навантаження RAMDISK етап буде терпіти невдачі і установка буде тоді знати, щоб запустити з компакт-диска, а не від RAMDISK. (Інсталюється використовується для роботи> машини 8М. Це все ще вірно?)
  • Спробуйте, в одній сесії, щоб очистити диск всіх розділів, які будуть використовуватися на Linux. Перевантажте. Потім спробуйте встановити. Або шлях поділу вручну або дозволити програмі установки цифрі. (Я розумію, що Red Hat має таку можливість теж SuSE є це…) Якщо це працює для вас, я був би вдячний, якби ви сказати мені.
  • Пошкоджені завантаження також можуть привести до цього. Брр.
  • Хтось повідомляє, що не встановлюється на машинах 8 Мб більше не працюють, і що установка недобірно виходить з sig7. — Кріс Рокко (crocco@earthlink.net)
  • Одна людина повідомляє, що відключення “BIOS shadow” (система та ВІДЕО), спрацювало. Оскільки Linux не використовує BIOS, затінення не допомагає. Деякі комп’ютери можуть навіть дати вам 384k додаткової оперативної пам’яті, якщо відключити стеження. Просто вимкніть його, і подивитися, що відбувається. – Філіп д’Оффей (pdoffay@pmdsoft.com).

ЗАПИТАННЯ
Які інші можливості?

ВІДПОВІДЬ
Інші відзначили такі можливості:

  • Укладач і Libc включені в Red Hat 5.0 мають непарну взаємодія з процесором Cyrix. Він розбиває компілятор, це ДУЖЕ дивно. Я думаю, що єдиний спосіб, яким це може бути випадок, коли Cyrix є помилка, що не виявлена весь цей час, і надійно спрацював, коли ЦЕ gcc компілює ядро Linux. У всякому разі, якщо ви просто хочете скомпілювати ядро, ви повинні отримати новий компілятор і/або Libc з сайту Red Hat. (Початок на головній сторінці, і натисніть помилки).
  • Компіляція ядра 2.0.x з 2.8.x gcc або іншим egcs не працює. Є кілька помилок в ядрі, які не показують, бо gcc 2.7.x робить паршиву роботу його оптимізації. gcc 2.8.x і еgcc просто скинути частину коду, тому що ми не сказали його не робити цього. У всякому разі, ви зазвичай ядро, яке, здається, працює, але є смішні помилки. Наприклад X може відбутися збій з сигналом 11. О, і перш, ніж ви запитаєте, ні, це не буде виправлено. Не турбувати Алана або Лінуса про це ОК? – Ганс Пітер Верн (h.p.verne@kjemi.uio.no)
  • Пентіум-оптимізуючий-gcc (коли номер версії закінчується на “p”) зазнає невдачі з параметрами за замовчуванням на деяких вихідні файли, як floppy.c в ядрі. У “тригери” знаходяться в ядрі, libc і в самій gcc. Це легко діагностовані як “не проблема апаратного забезпечення”, тому що це завжди відбувається в тому ж самому місці. Ви можете відключити деякі оптимізації (спробуйте -fno-розгортає-петлі) або використовувати інший gcc. — Еван Ченг (evan@top.cis.syr.edu) (Інакше: gcc 2.7.2p зазнає аварії з sig11 на floppy.c . Вихід-1: використовуйте просто gcc. Вихід-2: уручну компілюйте floppy.c з “-O” замість “-O2”. )
  • Погане з’єднання між диском і системою. Наприклад IDE кабелі допускаються тільки 40 см (16″) завдовжки. Багато системи поставляються з більш довгими кабелями. Також знімний IDE стійка може додати досить проблем до збою системи.
  • Погана конфігурація gcc — деякі частини з однією версією, деякі з інших. Через кілька тижнів я в кінцевому підсумку Повторно його з нуля, щоб отримати все правильно. – Річард Дерр III (rhd@Mars.mcs.com).
  • Gcc або в результаті чого додаток може закінчуватися sig11, коли програма пов’язана проти SCO бібліотек (з iBCS). Це відбувається в деяких додатках, які мають -L/lib у LDFLAGS….
  • При компіляції ядра з ELF компілятора, але налаштований для a.out (або навпаки, я забув), ви отримаєте сигнал 11 на першому виклику “ld”. Це легко визначається як проблема програмного забезпечення, як це завжди відбувається на перший виклик “ld” під час побудови. — РУ
  • Ethernet карта разом з погано налаштованої BIOS PCI. Якщо ваш (ISA) Ethernet карта має отвір на шині ISA, можливо, буде потрібно налаштувати його десь в екранах настройки BIOS. В іншому випадку апаратні засоби будуть виглядати на шині PCI для загальної області пам’яті. Оскільки ISA-карта не може реагувати на запити на шині PCI, ви читаєте порожній “повітря”. Це може привести до несправності сегментації і збоїв ядра. — РУ
  • Пошкоджений розділ підкачки. Тоні Нуджент (T.Nugent@sct.gu.edu.au) повідомляє, що він мав звичай мати цю проблему і вирішити її за допомогою mkswap на його розділ підкачки. (Не забудьте ввести “синхронізації”, перш ніж робити що-небудь ще після mkswap. – Луїс Дж. Лабаш молодший. (lou@minuet.siue.edu))
  • NE2000 card. Певні дешеві Ne2000 карти можуть зіпсувати систему. — Денні тер Хаар (dth@cistron.nl) Я особисто, можливо, мав схожі проблеми, так як мій поштовий сервер розбився жорсткий кожен зараз і потім (раз на день). Тепер здається, що 1.2.13 і багато в 1.3.x ядер мають цю помилку. Я не бачив його в 1.3.48. Ймовірно, десь була виправлена в той же час…. — РУ
  • Джерело живлення? Ні, я так не думаю. Сучасна важка система з двома або три вінчестером, як SCSI і IDE не перевищуватимуть 120 Вт або близько того. Якщо у вас є навантаження старих вінчестерів і старих карт розширення вимог до потужності будуть вище, але все одно це дуже важко досягти меж джерела живлення. Звичайно, деякі люди примудряються знайти вантажі старих вінчестерів повнорозмірних і встановити їх в їх велику вежу. Ви дійсно можете перевантажити PowerSupply таким чином. – Грег Ніколсон (greg@job.cba.ua.edu) Несправний блок живлення МОЖЕ, звичайно, поставити граничну потужність, що призводить до всьому несправним, що ви читали в цьому файлі…. – Торстен Куенманн (thorsten@actis.de)
  • Непостійний ext2fs. Деякі обставини можуть привести код ядра файлової системи ext2, щоб привести Signal 11 до Gcc. — Мортен Уеліндер (terra@diku.dk)
  • Батарея CMOS. Навіть якщо ви встановите BIOS, як ви хочете, це може бути зміна назад в “погані” настройки під носом, якщо батарея CMOS погано. – Геонмін Лім (coco@me.umn.edu)
  • Відсутній або занадто мало простору підкачки. Gcc некоректно обробляти “з пам’яті” стан. – Пол Бреннан (brannanp@musc.edu)
  • Несумісні бібліотеки. Якщо у вас є символьне посилання з “libc.so.5”, вказуючи на “libc.so.6“, деякі додатки будуть бомбити з sig11. – Пієт Брукс (piete.brooks@cl.cam.ac.uk).
  • Поламана миша. Так чи інакше, миша, здається, в стані зламати таким чином, що це викликає деякі програми (пов’язані з мишею), щоб врізатися з Sig11. Я бачив це на X-сервер, який буде врізатися, якщо ви перемістили миша швидко. Меттью Майт навіть не транспортувалися його мишею. — РУ та Метью Дугган (stauff@guarana.org).
  • Погано сидить RAM. Переконайтеся, що RAM правильно встановлена в гніздо…. – Керролл Конг (me@carrollkong.com).

ЗАПИТАННЯ
Я виявив, що працює….. виявляє помилки набагато швидше, ніж просто компіляції ядра. Будь ласка, вкажіть це на вашому сайті.

ВІДПОВІДЬ
Багато людей по електронній пошті мені з примітками, як це. Однак те, що багато хто не розуміє, що вони зіткнулися в одному випадку проблемного обладнання. Особа, рекомендуючи “unzip-t” сталося мати певну зламану палицю пам’яті DRAM. І розпакуйте сталося з “знайти”, що набагато швидше, ніж компіляції ядра.

Проте, я впевнений, що для багатьох інших проблем, ядро ​​компіляція знайде його, в той час як інші тести не роблять. Я думаю, що ядро ​​компіляції добре, тому що він підкреслює багато різних частин комп’ютера. Багато інші тести просто здійснювати тільки один район. Якщо ця область трапляється бути розірвана в вашому випадку, це покаже проблему набагато швидше, ніж “ядро компіляції” воля. Але якщо ваш комп’ютер ОК на цій області і зламана в інший, “швидше” тест може просто сказати вам, ваш комп’ютер в порядку, в той час як тест компіляції ядра сказав би вам щось не так.

У будь-якому випадку, я міг би точно так же перелічити те, що люди думають, що хороші тести, вони є, але не так взагалі як тест “спробувати скомпілювати ядро”….

  • запустіть розпакування під час компіляції ядра. Використовуйте файл архівації настільки ж великий, як RAM.
  • використовуйте “memtest86” з: http://www.memtest86.com/.
  • do dd if=/dev/hda of=/dev/null під час компіляції ядер.
  • запустіть md5sum для великих директорій.

Зверніть увагу, що будь-який швидкий метод ви можете знайти, щоб сказати вам, що ваш комп’ютер зламаний, це не гарантуватиме ваш комп’ютер добре, якщо такий тест раптом не підведе більше. Я завжди рекомендую після возитися з речами, щоб змусити його працювати, ви повинні запустити тест ядра компілювання 24-годинний.

ЗАПИТАННЯ
Чому не “memtest86” першим, щоб спробувати, якщо я підозрюю, що проблеми з пам’яттю?

ВІДПОВІДЬ
Не соромтеся робити це. Деякий це чорна магія. Однак, коли “memtest86” говорить вам, що ваша пам’ять в порядку, ви можете бути схильні вірити. Це говорить про те, що він не зміг знайти будь-яких проблем. Це не говорить вам, що ваша пам’ять бездоганна.

З мого досвіду, проблеми, пов’язані з RAM іноді не знайдені за допомогою тестера пам’яті. Візерунки все добре і регулярно. Деякі проблематичною RAM просто добре працює під такого роду стрес, але зазнає невдачі при більш безладними моделей стресу, викликаних “gcc” або “zip”.

Таким чином, я рекомендую вам спробувати перевірки системи за допомогою ядра компілюється, а не довіряючи тестер пам’яті….

ЗАПИТАННЯ
Я не вірю в це. Із ким це сталося?
ВІДПОВІДЬ
Ну, по-перше, це трапилося зі мною особисто. Але ви не повинні вірити мені. Це також сталося з:
• Джонні Стівенс (icjps@asuvm.inre.asu.edu)
Дії Іліч (d92dejil@und.ida.liu.se)
Рік Тесснер (rick@myra.com)
Девід Фокс (fox@graphics.cs.nyu.edu)
Даррен Уайт (dwhite@baker.cnw.com) (кеш L2)
Патрік Дж. Патрік Волкердінґ (volkerdi@mhd1.moorhead.msus.edu)
Джефф Кой-молодший (jcoy@gray.cscwc.pima.edu) (проблеми з температурою)
Майкл Блендфорд (mikey@azalea.lanl.gov) (проблеми з температурою: вентилятор процесора не працює)
Алекс Бутчер (Alex.Butcher@bristol.ac.uk) (пам’ять станів очікування)
Річард Постгейт (postgate@cafe.net) (VLB завантаження)
Берт Меіс (L.Meijs@et.tudelft.nl) (поганий SIMM)
Дж Ван Stonecypher (scypher@cs.fsu.edu)
Марк Кеттнер (kettner@cat.et.tudelft.nl) (поганий SIMM)
Нареш Шарма (n.sharma@is.twi.tudelft.nl) (30-> 72 перетворювача)
Рік Лім (ricklim@freenet.vancouver.bc.ca) (помилка кеша)
Скотт Брамбах (scottb@borris.beachnet.com)
Пол Гортмакер (paul.gortmaker@anu.edu.au)
Майк Тейтер (tayter@ncats.newaygo.mi.us) (щось з кешем)
Бенні??? (Benni@informatik.uni-frankfurt.de) (VLB перевантаження)
Олівер Шоетт (os@sdm.de) (кеш перемичка)
Мортен Уеліндер (terra@diku.dk)
Варвік Харві (warwick@cs.mu.oz.au) (біт помилки в кеші)
Хенк Барта (hank@pswin.chi.il.us)
Джеффрі Дж. Радич (jjr@zilker.net) (RAM напруги)
Семуеля РамаКо (sramac@vnet.ibm.com) (ЦП з вершин)
Ендрю Ескілсон (mpt95aes@pt.hk-r.se) (швидкість DRAM)
У. Пол Мілс (wpmills@midusa.net) (CPU вентилятор відключений від процесора)
Джозеф Бароне (barone@mntr02.psf.ge.com) (помилка кеша)
Філіп Тройн (ptroin@compass-da.com) (затримка ОЗУ проблеми синхронізації)
Коен д’Ондта (koen@dutlhs1.lr.tudelft.nl) (більш ядра повідомлення про помилки)
Білл Фауст (faust@pobox.com) (проблема кеша)
Тім Мідлкуп (mtim@lab.housing.fsu.edu) (температура CPU: встановлений вентилятор)
Ендрю Р. Кук (andy@anchtk.chm.anl.gov) (поганий кеш)
Вітер Аллана (wind@imada.ou.dk) (P66 перегрів)
Майкл Тушік (mt2@irz.inf.tu-dresden.de) (gcc2.7.2p жертва)
Р.C.Г. Лі (chli@en.polyu.edu.hk) (розгін: нормально протягом декількох місяців…)
Флорін (florin@monet.telebyte.nl) (розігнаний процесор від постачальника)
Дейл Дж. Марч (dmarch@pcocd2.intel.com) (центральний процесор від перегріву на ноутбуці)
Маркус Шульте (markus@dom.de) (помилка RAM)
Марк Девіс (mark_d_davis@usa.pipeline.com) (Bad P120?)
Хосеп Лладоноса Капель (jllado@arrakis.es) (опції PCI переоптимізація)
Еміліо Федерісі (mc9995@mclink.it) (Р120 перегрів)
Конор Маккарті (conormc@cclana.ucd.ie) (помилка SIMM)
Маттіас Петофалві (mpetofal@ulb.ac.be) ( “Simmverter” проблема)
Джонатан Крістофер Мак-Кінні (jono@tamu.edu) (gcc2.7.2p жертва)
Грег Ніколсон (greg@job.cba.ua.edu) (багато старих дисків)
Ісмо Пелтонен (iap@bigbang.hut.fi) (irq_unmasking)
Деніел Панкамо (pancamo@infocom.net) (70 нс замість 60 нс ОЗУ)
Девід Холс (david.halls@cl.cam.ac.uk)
Марк Сусман (marklz@pointer.israel.net) (помилка материнської плати)
Елізабет Ейер (eca23@cam.ac.uk) (функції управління живленням)
Торстен Куенманн (thorsten@actis.de)
© 1996-2017 – BitWizard B.V. is a registered trademark
© 1996-2017 BitWizard B.V. є зареєстрованим товарним знаком

 

About The Author

admin

Comments are closed.