Полигон-2

[q]

ессно почистить логи, потом забить _нулями_целиком_
AT_PDL, AT_POL, ZBRT, DMCS, HUTIL\HUSR передернуть питание
дать вендор-команду очистки листов(при этом сабж сам соберет нужные структуры дефект-мененжмента)
ну и ессно пнуть скан
(С) Sable

[/q]

[q]

Flaw Scan... Тест ID 75. Какой-то из 7-ми параметров - очевидно "придирчивость" теста, а какой-то - допустимое количество ошибок.
замечено, что в линейке тестов 70-75-70 он обычно проходит без проблем, а вот следующий 75-й тест в крипте - бывает, что и затыкается (по переполнению логов?) Различаются они 2-мя параметрами, 1-м и 5-м.
Но.. на SABRE отсутствует как класс линейка 70-75-70, там линейка 70-70 (с разными значениями (на единичку) в 1-м параметре. Дальше ожидание внешнего события (с каким-то бредом в параметрах, причем два раза... - очень непонятный момент... может он тут чего по терминалу ждет ?), загрузка сервопараметров, 75-й тест, снова загрузка сервопараметров и тот-же 75-й тест. Различаются только 1-м параметром.

А вот про "тест сжатия треков", ID 7D который... ничего умного сказать не могу... Но на нем, в том числе, режется объем. По всей видимости какой-то из параметров (возможно 1-й) - тоже пиковое значения для анализа результатов 38-го теста (оптимизации).

"ждать до упора" есть в параметрах теста ИД06 (wait for external event).
он-же Infinty bit в 6-м параметре, если ничего не путаю.

[/q]

[q]

Да, есть такие звери без модулей группы "А" в "С".
Наглядный пример лежит на столе.
D6FYP1, YAR41VW0, 6Y060L0620411, KGCD, в сейфе - YAR428WZ
Пока пасиент сам себе адаптивы пересчитывает попробую описать свою точку зрения на это дело.
Итак, исходные данные:
1. "Заветным ключиком" в "завестом листе" винт в "С" не вываливается. БИЗИ.
2. Да и фик с ним, пытаемся вычитать альтернативку из основной - ну.... почти удачно. За одним исключением: Читается она, мягко говоря, странно... Теряет серву, зависает... Бубен, танцы.. прочитали ПОЧТИ все. Но: после чтения последнего сектора в 1-й копии модулей - зависает наглухо, не снимая зависон даже резетом. Делаем вывод... там не то, чтобы неотформатировано... Там похоже банально просто НЕТ сервы... Или фирмварь "её готовить не умеет". Или я что-то делаю не так. Хрен с ним, делаем лодыря, попадаем нормально в "С". Выясняем, что то, что после "первой копии" - суть приколы транслятора УБА. Реально там нету нифига.
3. Начинаем анализ считанного альт-трека. ДИСКРОМ и все оверлеи группы "С" присутствуют. Дефолтные модули дефект-менеджмента присутствуют. Скановые модули присутствуют. Версия скана - cal_tz13.
В "С" определился как YCR41VW0, 6Y080L2.
4. Начинаем анализ скрипта скана. В нем 8 шагов:
0. 0001 - Старт тестирования
1. 20F6 - "пустой тест"
2. 20F6 - "пустой тест"
3. ххF5 - Комментарий, "Wait to move Rack"
4. 0006 - Ожидание внешнего события N минут, очевидно 15
5. ххF5 - Комментарий, "Read to Trim 2"
6. 0090 - Подготовка служебки
7. 0000 - Конец тестирования
Итак, Больше всего нам интересен тесты 4,6 и комментарий к тесту нумбер 5.
Уж очень много "смыслов" у слова "trim". Остановимся на "готовность".
Дальше идет чистое "ИМХО".
Ху из "ожидание внешнего события"? Осознавая, что у макторов тоже есть COM-терминал, могу предположить, что это самое "внешнее событие" - ничто иное, как ожидание сигнала от терминала и, возможно, потоковая SLDL загрузка базиса "А" служебки. 6-й тест в скрипте - ничто иное как эта самая "потоковая заливка" служебки "А", возможно напрямую "терминал - буффер-блин". Дальше винт просто резетится (возможно тоже по терминалу). И пинается скан из "А", без упоминаний о "С".
Все такие калипсы - ПЕРВЫЕ у Макстора, на них отрабатывалась идеология...

[/q]

[q]

Альтернативная нужна только для формирования основной. Так что, если в служебке А все в порядке, ну и запускайте из нее. Из С имеет смысл запускать только при наличии разрушений модулей, которые не удается восстановить. Селфскан все равно после теста Рестарт накопителя переключится в А и основные тесты пойдут уже оттуда.

[/q]

[q]

1. Пускаем винт _стандартно_ в основную варь.
2. Проводим тест записи(мне правда непонятно зачем. но как я уже говорил, АСЕ -рекомендует )
3. Записываем "вытащеные" из альт модули: 1f/37/1b/1d/18/78/33/93 ("чистые" паспорт/транслятор служебки/G-List/DMCS/итд.)
(пишем все сразу не передергивая питания и т.д.), на системную голову(в нашем случае - 3_я.
4. Дергаем питание и переопределяем винт(изменилась модель, зонник и т.д.), на всякий случай. заглянем в дефектлисты. Они должны быть девственно чистыми и вся конфигурация винта, должна быть старшей моделью для этого типа.
5. В конфиге винта, так же убираем способность реллокейта и защитного стирания, разумеется сохраняем эти изменения. перегружаем винт.
6. По ВСЕМ головам(в нашем случае, по 2 и 3_ей) "чистим" модули:
11,43,4С(в принципе можно его не чистить) и правим по ВСЕМ головам модуль скрипта(0Е). Ремапим все тесты по 89(включительно) кроме 01. ПРОВЕРЯЕМ ПРОДЕЛАНОЕ!!! И только после этого, переходим к пункту 7.
7. тут есть два варианта:
а) пихаем скан командой(АСЕ_вая утила может)
в) правим модуль 1f(АСЕ_вая утила может)
8. Мониторим прохождение скана.(желательно пользоваться альтернативной "смотрелкой". У АСЕ_вой нет возможности подглядеть, по какой голове проблемы, а это не хорошо
9. если скан где-то встал\завис. смотрим состояния регистров в этот момент...и...долго думаем, думаем, ну а что непонятно, спрашиваем!

[/q]

[q]

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

[/q]

[q]

для н40п, а может и для всех покеров
Можно в ФАК

WORD Max_CS(char *b,WORD len)
{
WORD csm=0;
WORD l=len/2-1;
_asm {
push esi
push ebx
push edx
xor edx,edx
xor eax,eax
mov esi,b
mov dx,1
mov ecx,l
mov ebx,csm
ll:
rol bx,1
xor bx,dx
lodsw
add bx,ax
loop ll

rol bx,1
xor bx,dx
neg bx

mov csm,ebx

pop edx
pop ebx
pop esi

}
return csm;
}

[/q]

[q]

а на ДСП подскажите
Если не ошибаюсь, то там просто суммирование, минимальная модификация кода

[/q]

[q]

K.C = FFFF-(X без последнего слова)
X - сумма по словно, с учетом что-
"Следует так же принять во внимание,что байты в слове
хранятся в виде младший байт_старший байт" © Хрюша

[/q]

[q]

"Второй" транслятор SA зоны слетел.
Первопричина скорее всего аппаратная, глюки системной головы.

[/q]

[q]

На платке калипсы в КЗ погорел 8-ми ногий дип-транзюк обозначеный как Q500. Cудя по всему это формирователь -5 в банку. На нем маркировка 20PFS20V. Есть еще платка с калипсы, там на ентой деталюхе маркировка W503 4G. Есть платка от антенны плоской, там стоят полевики по выходам VCM и SD. Маркировка PHN210T. Вопрос в том - кого и как туда поставить взамен дохлятины?

[/q]

[q]

Это сборка полевиков. На ней собран преобразователь -5в.
Недавно тоже была калипса с дохлой 20PFS20V. Но у меня она выгорела вместе
с L7250E и дорожкой где-то внутри платы... Взял с другой калипсы - маркировка
тоже совершенно другая была, поменял - работает Так что можно менять.

Прозвони дорожку на землю на дроссель преобразователя -5в. У меня она тоже отгорела.

[/q]

[q]

Я на днях ARES боролся, заголовки поправил, бобик вроде ожил, начал по логике сканить, а там... Короче чем больше заносишь дефектов тем становиться хуже. С пустыми листами и то вроде картина получше.

[/q]

[q]

Дам один намек... (Больше - религия не позволяет):
При ОТСУТСТВИИ одного из оверлеев, точно не помню (какогото из 1х, но не 1С и 1В) при прогоне записью по всей поляне дефекты в дефект-листы НЕ заносятся, но транслятор пересчитывается накопителем вполне исправно.
После чего работает как часики. Помогает при описанной проблеме

[/q]

[q]

Это калипса.
Это асина утиля, которая калипсин п-лист не идентифицирует.
Кароче, ничего страшного.

[/q]

[q]

Цитата: Делаем перенос из G в P. Висим Висим 5 часов. Висим 10 часов. Мне это надоеает и передёргиваю питание. После этого кроль дохнет полностью Стук, никакие лоадеры, игрушки с памятью и даже своп не могут их вывести из стука
DOS-лабой делал перенос видимо? Я ещё пару-тройку месяцев тому назад подобную ситуацию обрисовал. Тогда мне помог метод с замыканием входов проца(с комутатора) некоторой ёмкостью и подгрузкой нужного лодыря(сейчас знаю более цивилизованый метод). Отстучался он немного, потом ввалился в утиль . Убитым оказался в том числе и модуль DISK(ID1F). Поэтому конфигурацию головок крол неправильно понимал - вот и стук! Поправил я ему всё что померло, вобщем поднял крола.Больше не использую эту функцию на Калипсах(особо в DOS-лабе) и другим не советую - методы есть и получше.
p.s. Реанимация производилась уже WIN-лабой.

[/q]

[q]

А переносим как....утилей от АСЕ? Там был глюк на старых версиях, даже на зарегенных. Больше определенного колличества, винт именно впадал в транс. Я про перенос из Г листа в П лист. приходилось по немногу...по 50..проходило всегда.

Перенос из Г в П лист одной командой проходит. Так что если дефектов много скорее глюк прошивки/дефект поверхности СЗ в том месте куда пытается писать фирмваря. Мое мнение. Места под П лист достаточно - 139h(313) секторов.
На ДСП ромулусе 500 дефетов секунд за 30 переносило за один раз.

[/q]

[q]

У подопытного накопителя поверхность примерно 3 процент в начале диска и процентов 10 в конце убиты в хлам. Дефектов примерно 5 тысяч. Так вот примерно когда этой цифры достигаю, то накопитель глюковать начинает. Уходит в бизи при любых операциях с дефектами. Скрывать в п-лист не получается никаким способом. Вот я и подумал что может быть п-лист уже под завязку забит, отсюда и глюки. (ещё интересно, г - лист заполняется только до 636 дефектов и ни одним больше, хотя утилита пишет что г-лист на 3000 с чем то дефектов)

[/q]