Bug 2648 - memtest86 crashes at startup, if run on system with Intel Pentium M (Centrino) CPU
: memtest86 crashes at startup, if run on system with Intel Pentium M (Centrino...
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/memtest86)
: unstable
: all Linux
: P4 major
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2003-06-09 20:31 by
Modified: 2006-03-03 10:21 (History)


Attachments
0002648-memtest.diff.gz (2.45 KB, application/x-gzip-compressed)
2003-06-09 20:31, Andrey Liakhovets
no flags Details
CPU's info of computers tested with memtest86-3.0-alt4 (1.77 KB, application/octet-stream)
2003-10-03 16:57, Andrey Liakhovets
no flags Details
Detects (and works on) VIA C3, as well as works on Centrino (2.82 KB, application/x-gzip-compressed)
2003-10-03 17:04, Andrey Liakhovets
no flags Details
intel centrino, via c3 and amd athlon support for memtest86 3.0 (11.49 KB, patch)
2006-02-22 10:37, Michael Shigorin
no flags Details | Diff
CPUs tested with the latest patch (3.0-alt[6-8]) (1.77 KB, application/octet-stream)
2006-02-22 10:38, Michael Shigorin
no flags Details
README for the patch (in Russian) (2.37 KB, text/plain)
2006-02-22 10:40, Michael Shigorin
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2003-06-09 20:31:04
Версия: memtest86-3.0-alt3
Система: CPU: Intel Pentium M (Centrino)
При любом запуске программы (из boot-сектора дискеты, с
помощью grub или из-под DOS с помощью loadlin) на долю
секунды высвечивается экран с правильными цветами, затем
компьютер идёт на перезагрузку.
Чтение исходников показало, что CPU идентифицируется
программой как Intel Pentium 6xx неизвестной модели с
неизвестными кэш-дескрипторами, в результате размер кэша
полагается =0, после чего при определении скорости памяти
выполняется деление на этот 0 (init.c, функция memspeed).
---

---
Предлагаю добавить проверку на 0 переменных len и iter в
функцию memspeed (файл init.c) и сделать более правильную
идентификацию интеловских x86-процессоров (см. приложенный
diff-файл). Кроме того, в прилагаемом diff\'е разделена кэш
1-го уровня на code и data, где возможно (для интеловских),
и для расчётов скоростей используется размер data-кэш.
Я проверил получившуюся программу (сборка под ALM2.2) на
доступных мне системах -- работает (Intel Pentium M, 4, III,
Celeron). Информация получена из Intel Architecture Software
Developer\'s Manual, Volume 2: Instruction Set Reference
(<a href="http://developer.intel.com/design/pentium4/manuals/245471.htm">http://developer.intel.com/design/pentium4/manuals/245471.htm</a>), описание команды CPUID.
Возможно, разделение кэша 1-го уровня на code и data пока
особого смысла не имеет, получающиеся скорости от запуска к
запуску всё равно достаточно сильно меняются (по крайней
мере, на доступных мне ноутбуках).
------- Comment #1 From 2003-06-09 21:22:17 -------
Патч, будучи приложенным, приводит к циклическому выводу
\&quot;1000\&quot;/\&quot;0200\&quot; в разных пропорциях на P4 и C3.

На P4 -- проверяли?

PS: для большей оперативности use mail/jabber: <a
href="mailto:mike@altlinux.org" target="_new">mike@altlinux.org</a>
------- Comment #2 From 2003-06-09 21:22:17 -------
Патч, будучи приложенным, приводит к циклическому выводу
\&quot;1000\&quot;/\&quot;0200\&quot; в разных пропорциях на P4 и C3.

На P4 -- проверяли?

PS: для большей оперативности use mail/jabber: <a
href="mailto:mike@altlinux.org" target="_new">mike@altlinux.org</a>
------- Comment #3 From 2003-06-10 14:37:45 -------
Да, проверял, сейчас перепроверил ещё раз -- работает.
Результаты CPUID на этом процессоре:
Input EAX:  Output EAX Output EBX Output ECX Output EDX
 00000000:    00000002   756E6547   6C65746E   49656E69
                          u n e G    l e t n    I e n i
 00000001:    00000F27   00010809   00000400   BFEBF9FF
 00000002:    665B5101   00000000   00000000   007B7040
 80000000:    80000004   00000000   00000000   00000000
 80000001:    00000000   00000000   00000000   00000000
 80000002:    20202020   20202020   20202020   6E492020
                                                n I    
 80000003:    286C6574   50202952   69746E65   52286D75
               ( l e t    P   ) R    i t n e    R ( m u
 80000004:    20342029   20555043   30342E32   007A4847
                 4   )      U P C    0 4 . 2      z H G
(до этого проверял на процессоре P4, отличающемся только частотой и,
соответственно, у него отличался только результат CPUID при inp.EAX=80000004:
out.ECX = 30382E32).
 Андрей Ляховец
------- Comment #4 From 2003-06-10 14:37:45 -------
Да, проверял, сейчас перепроверил ещё раз -- работает.
Результаты CPUID на этом процессоре:
Input EAX:  Output EAX Output EBX Output ECX Output EDX
 00000000:    00000002   756E6547   6C65746E   49656E69
                          u n e G    l e t n    I e n i
 00000001:    00000F27   00010809   00000400   BFEBF9FF
 00000002:    665B5101   00000000   00000000   007B7040
 80000000:    80000004   00000000   00000000   00000000
 80000001:    00000000   00000000   00000000   00000000
 80000002:    20202020   20202020   20202020   6E492020
                                                n I    
 80000003:    286C6574   50202952   69746E65   52286D75
               ( l e t    P   ) R    i t n e    R ( m u
 80000004:    20342029   20555043   30342E32   007A4847
                 4   )      U P C    0 4 . 2      z H G
(до этого проверял на процессоре P4, отличающемся только частотой и,
соответственно, у него отличался только результат CPUID при inp.EAX=80000004:
out.ECX = 30382E32).
 Андрей Ляховец
------- Comment #5 From 2003-06-10 21:34:36 -------
Гм.  Можете прислать мне свою сборку и информацию о ее создании?
------- Comment #6 From 2003-06-10 21:34:36 -------
Гм.  Можете прислать мне свою сборку и информацию о ее создании?
------- Comment #7 From 2003-06-11 15:56:12 -------
Послал лично.
Есть предположение, что такой вывод может быть при ошибке чтения дискеты,
если запускать memtest86 из начальных секторов дискеты (файл bootsect.S,
цикл на метке load_setup:).
Попробовать запуск через GRUB, LILO, loadlin или другую дискету ?
 Андрей Ляховец
------- Comment #8 From 2003-06-11 15:56:12 -------
Послал лично.
Есть предположение, что такой вывод может быть при ошибке чтения дискеты,
если запускать memtest86 из начальных секторов дискеты (файл bootsect.S,
цикл на метке load_setup:).
Попробовать запуск через GRUB, LILO, loadlin или другую дискету ?
 Андрей Ляховец
------- Comment #9 From 2003-07-31 14:47:10 -------
--MARK--
------- Comment #10 From 2003-07-31 14:47:10 -------
--MARK--
------- Comment #11 From 2003-09-25 16:05:09 -------
Собрал сегодня по другим причинам alt4 (оставив Ваш патч) -- на двух
проверенных
системах (Athlon и P4) проблем не возникло.  Проверю остальные имеющиеся и буду
выкладывать; может, пока посмотрите 
ftp://ftp.altlinux.org/pub/people/mike/RPMS/memtest86-3.0-alt4.i586.rpm
ftp://ftp.altlinux.org/pub/people/mike/SRPMS/memtest86-3.0-alt4.src.rpm

Извините за долгий ящик -- не найдя решения проблемы тогда (дискету менял,
кажется) -- отложил вопрос.
------- Comment #12 From 2003-10-03 16:57:47 -------
Created an attachment (id=289) [details]
CPU's info of computers tested with memtest86-3.0-alt4

These CPU's have been also tested with my_viac3.diff patch.
------- Comment #13 From 2003-10-03 17:04:59 -------
Created an attachment (id=290) [details]
Detects (and works on) VIA C3, as well as works on Centrino
------- Comment #14 From 2003-10-03 17:06:25 -------
Проверил на Pentium M (Centrino) 1500, P4 (with HT) 3.06,
P4 2.80, Mobile P4 2.60, PIII 850, PIII 700, Celeron 667,
PII 400, Pentium 120 -- всё OK (см. tested_cpus.tar.gz,
первые строки - из memtest86, затем результаты CPUID
с комментариями).
 Работает также на VIA C3 1GHz, но, естественно, без
определения модели процессора и кэшей и без использования
Time Stamp Counter'а (т.е., без времени).
 Сделал патч, с которым определяет и доступный мне VIA C3
(my_viac3.diff.gz, включает и Centrino), проверил на тех же
аппаратах и на VIA (см. VIAC3_1 в tested_cpus.tar.gz).
Заодно поправил "skip reserved registers" в "get cache info"
(могли быть пропуски в отладочной печати) и немного изменил
расчёт скорости кэшей, -- во всяком случае, определение
скорости L1 data cache стало гораздо стабильнее, да и у
L2 теперь более реалистичные значения.
Но это уже можно рассматривать как feature request.

Андрей Ляховец
------- Comment #15 From 2003-10-06 12:51:20 -------
* Mon Oct 06 2003 Michael Shigorin <mike altlinux ru> 3.0-alt5
- updated patch by AL (now handles VIA C3 too); changed its company prefix
  from "alt" to "rover" as it should reflect the origin more properly
- added README.rover (see also #2648 history) and cpus/ to docs
- minor spec cleanup, TODO update
------- Comment #16 From 2006-02-22 10:35:43 -------
Adding last patch/readme versions that were present in memtest86-3.0-alt8; not
using them with 3.2 (patch doesn't apply and I cannot verify the result reliably
even if would successfully merge it -- which is highly doubtful).

Also notifying upstream and memtest.org.
------- Comment #17 From 2006-02-22 10:37:18 -------
Created an attachment (id=1398) [details]
intel centrino, via c3 and amd athlon support for memtest86 3.0
------- Comment #18 From 2006-02-22 10:38:52 -------
Created an attachment (id=1399) [details]
CPUs tested with the latest patch (3.0-alt[6-8])
------- Comment #19 From 2006-02-22 10:40:27 -------
Created an attachment (id=1400) [details]
README for the patch (in Russian)
------- Comment #20 From 2006-02-25 18:42:44 -------
Посмотрел исходники версии 3.2 в тех местах, которые я патчил.
Ну, стало лучше. И очень может быть, что работает на всех существующих CPU
(сейчас времени нет проверять).

Но главная мина так и осталась не обезвреженной:
как только появится новый процессор с неизвестным кэшем
(т.е. как только в функции cpu_type в init.c переменные l1_cache и l2_cache
останутся =0 к тому моменту, когда мы доберёмся до Determine memory speed),
так сразу будет вызвана memspeed с параметром len=0 и программа рухнет.
Так и не начав тестировать память всего лишь из-за никому не нужной
попытки определить (весьма приблизительно) скорость этой памяти.

Ещё раз "предлагаю добавить проверку на 0 переменных len и iter в
функцию memspeed (файл init.c)":
--- init.c.orig 2004-11-09 22:57:44 +0300
+++ init.c      2006-02-25 18:13:59 +0300
@@ -931,6 +931,10 @@
        ulong wlen;
        int i;

+       if (len == 0 || iter == 0) {
+               return 0;
+       }
+
        dst = src + len;
        wlen = len / 4;  /* Length is bytes */

По поводу всего остального просто неохота (и нет времени) возиться.

С патчами к версии 3.0 было гораздо проще: не хватало кэш-дескрипторов,
не было Brand ID и т.д. Было ясно, что надо бы это добавить
(раз уж занимаемся определением CPU и cache).
А теперь...
Может, у авторов этого кода более правильная документация и/или
больше возможностей тестирования, -- разбираться довольно долго.

Так что пусть определяют как-нибудь, лишь бы не падало при этом.
Нам же тестировать надо, а не определять нечто известное и совершенно
не нужное для тестирования.
------- Comment #21 From 2006-03-03 10:21:02 -------
Алексей, спасибо -- принято в 3.2-alt2 и отправлено разработчикам.