URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 55700
[ Назад ]
Исходное сообщение
"тест памяти у SUN"
Отправлено Zhelezniy_Felix , 19-Апр-05 13:25 
будучи херовым сантехником прошу у вас совета

есть сан у него гига 4 оперативки.... виднно одна банка сбойная... нужна какаянить прга чтобы проверить память там какойто memdiag гдето в природе существует но чтобы его поставить какието непонятные действия нада выпонитьъ

еще есть ли в природе какиенить ливсиди диски линукса для спарк ? можт это проще будет грузанятся и оттудовой какнить протестить память ?


жду мыслей в студию

Содержание
Сообщения в этом обсуждении
"тест памяти у SUN"
Отправлено kolayshkin , 19-Апр-05 15:03 
>будучи херовым сантехником прошу у вас совета
>
>есть сан у него гига 4 оперативки.... виднно одна банка сбойная... нужна
>какаянить прга чтобы проверить память там какойто memdiag гдето в природе
>существует но чтобы его поставить какието непонятные действия нада выпонитьъ
>
>
>
>еще есть ли в природе какиенить ливсиди диски линукса для спарк ?
>можт это проще будет грузанятся и оттудовой какнить протестить память ?
>
>
>
>жду мыслей в студию


Попробуй пакет SunVTS . Найти его можно на sunsolve.sun.com . Поставишь его , потом патчи на него и попробуй протестить. Тестирует всё железо. Но только нет гарантии что он найдет сбойную память. А какте симптомы то хоть?

"тест памяти у SUN"
Отправлено lavr , 19-Апр-05 15:17 
>>будучи херовым сантехником прошу у вас совета
>>
>>есть сан у него гига 4 оперативки.... виднно одна банка сбойная... нужна
>>какаянить прга чтобы проверить память там какойто memdiag гдето в природе
>>существует но чтобы его поставить какието непонятные действия нада выпонитьъ
>>
>>
>>
>>еще есть ли в природе какиенить ливсиди диски линукса для спарк ?
>>можт это проще будет грузанятся и оттудовой какнить протестить память ?
>>
>>
>>
>>жду мыслей в студию
>
>
>Попробуй пакет SunVTS . Найти его можно на sunsolve.sun.com . Поставишь его
>, потом патчи на него и попробуй протестить. Тестирует всё железо.
>Но только нет гарантии что он найдет сбойную память. А какте
>симптомы то хоть?

еще лучше прочитать руководство по PROM(EEPROM), выполнить shutdown
прервать загрузку STOP-A - выйти в prom:

ok help
ok help setenv
...
ok setenv selftest...
...
ok help test
ok test /memory

"тест памяти у SUN"
Отправлено Vakero , 19-Апр-05 15:48 
>еще лучше прочитать руководство по PROM(EEPROM), выполнить shutdown
>прервать загрузку STOP-A - выйти в prom:
>
>ok help
>ok help setenv
>...
>ok setenv selftest...
>...
>ok help test
>ok test /memory


Предлагаю более точное решение:

1. Подключится ноутом или рабочей станицей с COM-портом (если есть рядом с серваком станция) нуль-модемным шнурком к COM-порту A Сановского сервака и запустить HyperTerminal или подобную терминальную софтину, включить лог сессии в софтине. Параметры поключения проги: 9600-8-N-1-H .
2. На Сане, с консоли:
- # init 0
Сервер выгрузиться в BootPROM
- ok setenv auto-boot? false
- ok setenv diag-level max
- ok setenv diag_switch? true
- ok diag-out-console true
- ok power-off
Сервер выключиться.
3. Включить сервак кнопкой питания, проверив, что ваша терминальная прога находиться в состоянии Connected.
4. Лог фулл-теста сервера будет сыпаться в терминал. 4Гб памяти, в зависимости от проца - это 30 минут теста. Если с памятью что-то не так - вы увидите наподобие вот такого:

0>Test 536870912 bytes on bank 1....
0>1% Done...
0>4% Done...
0>6% Done...
0>9% Done...
0>12% Done...
0>15% Done...
0>WARNING: TEST = Block Memory
0>H/W under test = CPU0, All CPU0 Memory
0>MSG = Data or Instruction Access Error,
Trap Type 00000000.00000032
Trap PC ffffffff.f013bb90
Trap Level 00000000.00000001
AFSR 00100004.00000132
AFAR 00000001.0c280030
0>END_WARNING

0> PRIV bit: Privileged code access error(s)
0> UE bit: Uncorrectable system data ECC error
0>
Failed cache line data:
0> Address 00000001.0c280000=00000000.00000000.
0> Address 00000001.0c280008=00000000.00000000.
0> Address 00000001.0c280010=00000000.00000000.
0> Address 00000001.0c280018=00000000.00000000.
0> Address 00000001.0c280020=00000000.00000000.
0> Address 00000001.0c280028=00000000.00000000.
0> Address 00000001.0c280030=0000c000.00000000.
0> Address 00000001.0c280038=00000000.00000000.
0> AFSR check after re-reading data:
0> No Errors in afsr reg
0>ERROR: TEST = Block Memory
0>H/W under test = CPU0, All CPU0 Memory
0>Repair Instructions: Replace items in order listed by 'H/W under test' above.
0>MSG = ERROR: miscompare on mem test!
Address: 00000001.0c280030
Expected: 00000000.00000000
Observed: 0000c000.00000000
0>END_ERROR

0>ERROR: TEST = Block Memory
0>H/W under test = CPU0 Bank 1 Dimm 0, J0101 side 1
0>Repair Instructions: Replace items in order listed by 'H/W under test' above.
0>MSG = DIMM failure Bank 1 DIMM 0 Pin 98
0>END_ERROR

0>ERROR: TEST = Block Memory
0>H/W under test = CPU0 Bank 1 Dimm 0, J0101 side 1
0>Repair Instructions: Replace items in order listed by 'H/W under test' above.
0>MSG = DIMM failure Bank 1 DIMM 0 Pin 99
0>END_ERROR

0>Test 2147483648 bytes on bank 2....
0>0% Done...
0>1% Done...
0>1% Done...

5. По окончании теста все параметры BootPROM выставляем назад с консоли или терминала:

- ok setenv auto-boot? true
- ok setenv diag-level min
- ok setenv diag_switch? false
- ok diag-out-console true (лучше оставить это навсегда)
- ok reset-all

Сервер должен начать перезагрузку.

Скажу с уверенностью, что при таком результате теста вы никогда не загрузите сервер, пока не поменяете сбойную планку или не снимите весь банк планок (тогда можно запуститься на оставшемся банке, если он у вас конечно есть).

Поэтому, предлагаю сначала внимательно оценить наличие в /var/adm/messages и в /var/adm/messages.x подобных строк:

Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 743168 kern.info] NOTICE: [AFT0] Corrected system bus (CE) Event detected by CPU2 at TL=0, errID 0x00092ff2.89bbf918
Jan 19 05:53:51 sun1 AFSR 0x00000002<CE>.000000b9 AFAR 0x000000a1.0404b280
Jan 19 05:53:51 sun1 Fault_PC 0x117d7d0 Esynd 0x00b9 Slot A: J3101
Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 458619 kern.info] [AFT0] errID 0x00092ff2.89bbf918 Corrected Memory Error on Slot A: J3101 is Persistent
Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 426073 kern.info] [AFT0] errID 0x00092ff2.89bbf918 Data Bit 48 was in error and corrected
Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 636108 kern.info] [AFT2] errID 0x00092ff2.89bbf918 E$tag PA=0x000000b1.fd04b280 does not match AFAR=0x000000a1.0404b280
Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 610411 kern.info] [AFT2] errID 0x00092ff2.89bbf918 PA=0x000000b1.fd04b280
Jan 19 05:53:51 sun1 E$tag 0x000002c7.f4000101 E$state_2 Modified
Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 895151 kern.info] [AFT2] E$Data (0x00) 0x00000000.001c0025 0x800000b1.d82507b6 ECC 0x1ad
Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 895151 kern.info] [AFT2] E$Data (0x10) 0x00000000.000c0025 0x810000a1.f369a7b6 ECC 0x0de
Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 895151 kern.info] [AFT2] E$Data (0x20) 0x00000000.000c0025 0x820000a1.f369c7b6 ECC 0x185
Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 895151 kern.info] [AFT2] E$Data (0x30) 0x00000000.001c0025 0x830000b1.d82567b6 ECC 0x0f6
Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 636108 kern.info] [AFT2] errID 0x00092ff2.89bbf918 E$tag PA=0x000000a1.dc04b280 does not match AFAR=0x000000a1.0404b280
Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 610411 kern.info] [AFT2] errID 0x00092ff2.89bbf918 PA=0x000000a1.dc04b280
Jan 19 05:53:51 sun1 E$tag 0x00000287.70492492 E$state_2 Exclusive
Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 895151 kern.info] [AFT2] E$Data (0x00) 0x01ca03c2.174d0833 0x33313134.303031ff ECC 0x174
Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 895151 kern.info] [AFT2] E$Data (0x10) 0xffffffff.ffffffff 0x08333532.31343730 ECC 0x17b
Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 895151 kern.info] [AFT2] E$Data (0x20) 0x330d3039.36303730 0x38313530.3539320b ECC 0x036
Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 895151 kern.info] [AFT2] E$Data (0x30) 0x28522954.41524c45 0x56205009.32383031 ECC 0x17a
Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 929717 kern.info] [AFT2] D$ data not available
Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 335345 kern.info] [AFT2] I$ data not available

Данные сообщения говорят о наличие ошибок в планке и являются легитимным основанием для открытия сервисного запроса на замену планки (если конечно у вас есть сервис-контракт или гарантия).
Скажу больше - скорее всего у вас именно второй случай, потому что сервер у вас живет, в первом случае - он бы у вас ресетнулся и не грузился.

Успехов.

"тест памяти у SUN"
Отправлено Vakero , 19-Апр-05 15:51 
>- ok diag-out-console true

Здесь имеется ввиду:

- ok setenv diag-out-console true

Опечатка ))) Слишком быстро писал))

"тест памяти у SUN"
Отправлено Nikolaev D. , 19-Апр-05 21:58 
>- ok setenv diag-out-console true

после использования setenv вроде надо сказать reset-all  ??

"тест памяти у SUN"
Отправлено Vakero , 20-Апр-05 12:17 
>>- ok setenv diag-out-console true
>
>после использования setenv вроде надо сказать reset-all  ??

Внимательно читаем. Там указано power-off - работает не хуже reset-all )))

Просто сделав ресет, а не выключив машину на диаг-консоль ничего не получите - проверено. Можно еще ключик провернуть на положение диагностики, но это для ламеров )))

"тест памяти у SUN"
Отправлено jema , 21-Апр-05 18:45 
еще желательно зациклить тест OBP с помощью Shift+L...посмотреть что получится..циклов на 10 например
"тест памяти у SUN"
Отправлено Vakero , 22-Апр-05 10:49 
>еще желательно зациклить тест OBP с помощью Shift+L...посмотреть что получится..циклов на 10
>например

Если у товарища есть 5 часов свободного времени на такие эксперименты - ноу проблем.

"тест памяти у SUN"
Отправлено gob13 , 26-Апр-05 10:12 
Есть пример что мах диаг левел не всегда помогает Ё например я точно знаю что 8я планка с памятью битая и тесты проходят нормально
"тест памяти у SUN"
Отправлено Vakero , 26-Апр-05 14:10 
>Есть пример что мах диаг левел не всегда помогает Ё например я
>точно знаю что 8я планка с памятью битая и тесты проходят
>нормально

читаем внимательно текст в районе "...Скажу с уверенностью, что при таком результате теста вы никогда не загрузите сервер, пока не поменяете сбойную планку или не снимите весь банк планок (тогда можно запуститься на оставшемся банке, если он у вас конечно есть).

Поэтому, предлагаю сначала внимательно оценить наличие в /var/adm/messages и в /var/adm/messages.x подобных строк:... "

"тест памяти у SUN"
Отправлено Momonth , 04-Окт-05 07:12 
>Поэтому, предлагаю сначала внимательно оценить наличие в /var/adm/messages и в /var/adm/messages.x подобных
>строк:
>
>Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 743168 kern.info] NOTICE: [AFT0] Corrected system
>bus (CE) Event detected by CPU2 at TL=0, errID 0x00092ff2.89bbf918
>Jan 19 05:53:51 sun1 AFSR 0x00000002<CE>.000000b9 AFAR 0x000000a1.0404b280
>Jan 19 05:53:51 sun1 Fault_PC 0x117d7d0 Esynd 0x00b9 Slot A: J3101
>Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 458619 kern.info] [AFT0] errID 0x00092ff2.89bbf918 Corrected
>Memory Error on Slot A: J3101 is Persistent
>Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 426073 kern.info] [AFT0] errID 0x00092ff2.89bbf918 Data
>Bit 48 was in error and corrected
>Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 636108 kern.info] [AFT2] errID 0x00092ff2.89bbf918 E$tag
>PA=0x000000b1.fd04b280 does not match AFAR=0x000000a1.0404b280
>Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 610411 kern.info] [AFT2] errID 0x00092ff2.89bbf918 PA=0x000000b1.fd04b280
>
>Jan 19 05:53:51 sun1 E$tag 0x000002c7.f4000101 E$state_2 Modified
>Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 895151 kern.info] [AFT2] E$Data (0x00) 0x00000000.001c0025
>0x800000b1.d82507b6 ECC 0x1ad
>Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 895151 kern.info] [AFT2] E$Data (0x10) 0x00000000.000c0025
>0x810000a1.f369a7b6 ECC 0x0de
>Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 895151 kern.info] [AFT2] E$Data (0x20) 0x00000000.000c0025
>0x820000a1.f369c7b6 ECC 0x185
>Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 895151 kern.info] [AFT2] E$Data (0x30) 0x00000000.001c0025
>0x830000b1.d82567b6 ECC 0x0f6
>Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 636108 kern.info] [AFT2] errID 0x00092ff2.89bbf918 E$tag
>PA=0x000000a1.dc04b280 does not match AFAR=0x000000a1.0404b280
>Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 610411 kern.info] [AFT2] errID 0x00092ff2.89bbf918 PA=0x000000a1.dc04b280
>
>Jan 19 05:53:51 sun1 E$tag 0x00000287.70492492 E$state_2 Exclusive
>Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 895151 kern.info] [AFT2] E$Data (0x00) 0x01ca03c2.174d0833
>0x33313134.303031ff ECC 0x174
>Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 895151 kern.info] [AFT2] E$Data (0x10) 0xffffffff.ffffffff
>0x08333532.31343730 ECC 0x17b
>Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 895151 kern.info] [AFT2] E$Data (0x20) 0x330d3039.36303730
>0x38313530.3539320b ECC 0x036
>Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 895151 kern.info] [AFT2] E$Data (0x30) 0x28522954.41524c45
>0x56205009.32383031 ECC 0x17a
>Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 929717 kern.info] [AFT2] D$ data not
>available
>Jan 19 05:53:51 sun1 SUNW,UltraSPARC-III+: [ID 335345 kern.info] [AFT2] I$ data not
>available
>
>Данные сообщения говорят о наличие ошибок в планке и являются легитимным основанием
>для открытия сервисного запроса на замену планки (если конечно у вас
>есть сервис-контракт или гарантия).
>Скажу больше - скорее всего у вас именно второй случай, потому что
>сервер у вас живет, в первом случае - он бы у
>вас ресетнулся и не грузился.
>
>Успехов.

По поводу подобных строк в /var/adm/messages: http://www.sun.com/products-n-solutions/hardware/docs/pdf/81...
--- cut
Errors Categorized as Persistent

As indicated in the example in the previous section, the Solaris
software uses the
term Persistent to label correctable ECC events that are consistent
with naturally
occurring cosmic ray effects. Determining that a series of correctable
ECC events are
due to a defective DIMM and not simply a cosmic ray effect is an
important
question, because unnecessary changing of DIMMs due to cosmic ray soft
errors will
decrease the reliability of the system due to excessive handling and
human
intervention. While the long term plan is to enhance the Solaris
environment to
make service recommendations based on the internal tracking of event
rates, it is
currently necessary for Sun's service organization to follow
guidelines with respect
to servicing memory DIMMs. As of the writing of this document, the
current
published guidelines indicate that a single DIMM must experience three
correctable
ECC events, labeled Persistent, in a 24-hour period before service
should be
performed. If a DIMM experiences correctable ECC events with any less
frequency, it
is almost certainly due to cosmic ray events and therefore does not
warrant
replacement.