ARES C64K: слетели P-List и DMCS
Добрый день!
Дали на ремонт комп... Сдуру включил в BIOSе SMART, после чего винт Maxtor Fireball 3 стал определяться как ARES C64K. Данные винта:
Maxtor Fireball 3
2F030J0310211
VAM51JJ0
KMCA
A8FFA (над IDE-разъемом)
Нужна инфа с винта (архив фоток хозяев этого компа). Ремонтника нашел (hdd-911.com), но пока есть надежда, что сделаю сам. Понимаю, что надежнее отдать в ремонт, но пока ищу инфу по форумам, на винт ничего не пишу...
PC3000 v.14, pcmx_pkr v.2.01 (более свежей не нашел, кстати, может кто поделится??)
Проверка служебки:
# PN UBA Size Rd ChkSum Id Comment -------------------------------------------------------------------------------- 20 18 0029 0004 - - - AT_PDL - P-List 25 1D 02A0 0002 - - - DMCS - таблица кэширования 35 30 018B 0001 - - - SMART Attributes - атрибуты SMART 41 41 018D 0002 - - - 45 45 018F 000C - - - 68 63 018C 0001 - - - Копия SMART атрибутов 77 70 0356 0001 - - - SMART Summary Log
Соотв. этим модулям файлы имеют расширение .BAD. В группах модулей соотв. места заполнены строкой "BAD!", причем в обоих копиях (в DMCS - оба сектора, в AT_PDL - первые 4 сектора BAD, потом нули). Вычитывание с игнорированием ошибок ничего не дает.
Еще есть модули (кроме этого списка), у которых не в порядке только CRC.
Оверлеи в порядке. Дефектов в служебке нет. Тест записи в служебку проходит (смещение: 0). Ресурсы с винта предварительно слил.
Почитав форумы и доки, пришел к выводу, что нужно восстановить только AT_PDL и может быть DMCS. Определил следующую последовательность действий:
1. Запускаем DOS.
2. Подаем питание на винт (перемычка установлена в safemode).
3. Запускаем эмулятор, затем pcmx_pkr.exe.
4. Загружаем лоадер (в режиме ПЗУ+модули).
5. "Стандартный режим".
6. Прописываем модули AT_PDL и DMCS от другого винта.
7. Выходим из программы, выключаемся, запускаем все заново (пп. 1-5).
8. Запускаем пересчет транслятора. Модули транслятора (в т. ч. AT_PDL) будут пересобраны из 33-го модуля (он в порядке).
Вопрос 1. Это правильная последовательность действий? Может чего-то не хватает, или наоборот лишнее? Данные на винте останутся?
Вопрос 2. Могу ли я использовать текущий лоадер (ес-но, это лоадер от другого винта)? Или прохождение теста записи служебки однозначно показывает, что лоадер подходит?
Вопрос 3. Меня смущает, что PC3000 выдает, похоже, не полную информацию о винте.
Верхняя строка. MODEL: MaxtorARES C64K VAM51JJ0 CYL:-1 HEAD:1 SEC:0
Нижняя строка. STATE: DONE: LBA: ERRS: (все пусто)
В строке флагов "красных" битов нет.
Это нормально?
P.S. Вчера угробил свой старый Calypso 6Y080L0, на котором экспериментировал. Кушает некоторые лоадеры, но в них (в тех, что пробовал) не идет тест служебки, проверка служебки показывает нечитаемость большинства модулей, а также ПЗУ и оверлеев. Ресурсы с него все есть, но свой лоадер тоже почему-то не кушает... Ес-но, инфы на нем ценной нет, но теперь вдвойне аккуратен, выверяю каждый шаг.
Прошивка и настройка BIOS, переделка и ремонт материнских плат, БП, видеокарт, HDD.
ROM.by 2002-2019 © apple_rom
насколько я помню 4x модули в Maxtor -это модули нужные для проведения самотестирования ,самодиагностики.
Для обычной работы не используются.
Мда, не все так просто
Запускаю пересчет, запрос "Чистить G-list & P-list"? По выбору "Нет" ничего не происходит, жму Esc - сразу же выскакивает сообщение "Транслятор пересчитан успешно", и снизу загораются красные биты ERR и ABRT. После этого можно работать с программой дальше, красные биты потом гаснут. Версия pcmx_pkr у меня, напомню, 2.01.
Может записать эти 41 и 45 модули? Но они по идее не при чем к транслятору? Или это из-за ошибки контрольной суммы AT_PDL, который сейчас залит?
Может версия аси у кого посвежее есть (искал в нете - так и не нашел)?
P.S. В "Таблица дефектов" -> P-list - уже другой список дефектов. UPDATED - см. следующий пост.
В БИОСе по-прежнему определяется как ARES.
Еще кое-что... Решил проверить некоторые модули, изменились ли они:
SMART'ы: не изменились (= тем чужим, что я заливал)
AT_PDL: не изменился (по сравнению с чужим, который я заливал)
RZTBL: не изменился (по сравнению с родным)
DMCS: изменился (по сравнению с чужим)
33 модуль: изменился по сравнению с родным (??) правда, только несколько секторов в середине (33-48 считая с единицы), остальное не изменилось
U_LIST: изменился по сравнению с родным
Когда я прописывал чужие модули, они записывались корректно, ничего сверх этого не отличалось от родных ресурсов. Кроме некоторых модулей, связанных с оверлеями, и еще пары неизвестных модулей.
Потом я пытался запускать пересчет (3 раза). 1-ый раз - перед тем как спрашивал здесь, что отвечать на запрос об очистке P-list'а (я тогда нажал ESC). И сегодня 2 раза (ESC).
Т.е. как будто процедура пересчета запустилась, что-то изменила в U_LIST, в 33 модуле (??), и на этом завершилась, не выполнив все до конца и не дойдя до AT_PDL.
А может после 1-го запуска пересчета изменился U-LIST, и поэтому дальше все пошло наперекосяк? Но тест записи служебки проходил...
Еще интересно (и это радует!), что лог проверки структуры служебки - нормальный, от родного отличается как раз только модулями, которые я прописывал (см. ниже). G-list ("Таблица дефектов" -> G-list) не отличается от родного лога.
P-list - здесь интересно. 1-ым блоком отличаются (в родном логе было 487 дефектов, сейчас 1). А 2-ой блок - абсолютно такой же.
Нужно ли возвращать родной U_LIST, если понадобится что-нибудь писать в служебку (это ведь транслятор служебной зоны)? И смогу ли я вообще это сделать из-под своего лоадера? Или U_LIST не используется при работе из-под лоадера?
Структура служебки на данный момент:
Еще раз заранее спасибо за ответы.
Зря вы только чужой P-лист взяли. Он же не только на дефекты завязан, но и на трансляцию SA, и на зонные таблицы.
Можно переносить только сразу все модули участвующие в трансляции.
Лучше уж родной занулить. Если невозможно собрать его из копий.
Вернуть исходный 33, а потом пересчитать транслятор.
Но у Alexander_G ведь работало:
??
Т.е:
1. Сбрасываем P-List & G-list (только P-list нет возможности).
2. Возвращаем родные модули 33 и AT_POL (G-list).
3. Пересчитываем транслятор.
Так правильно?
И вопрос 2: U_LIST изменился - запись в служебку из-под этого лоадера будет корректной (U_LIST - это ведь транслятор служебки)? Винт в safemode ес-но, лоадер загружаю как ПЗУ+модули.
Да, а может лучше вариант 2:
1. Заливаем чужие U_LIST, AT_PDL (P-list), RZTBL.
2. Заливаем родной 33.
3. Пересчитываем транслятор.
Какой из 2-х вариантов лучше??
"Успешно пересчитан" - просто дежурная фраза на конец программы, в этом случае - очередной глюк. Красные биты Err и Abrt - ошибка пересчета. Т. е., транслятор реально не пересчитался и работать дальше нельзя.
Надо разбираться, что мешает. Я бы на самый простой случай попробовал очистить g-list (может какой мусор в g-liste) и сделал восстановление модулей DMCS и P-list (просто пересчёт контрольной суммы). После этого ещё раз попробовать пересчитать транслятор.
Если не поможет - дальше думать. Может действительно придётся таблицу p-lista чистить.
G-list еще проверю, изменился ли сам модуль AT_POL по сравнению с родным (я смотрел только лог). Но по идее G-list не причем к транслятору? Хотя кто его знает, не зря же в проге очистить можно либо P-list & G-list, либо только G-list.
Восстановление модулей (DMCS) - как я понял, восстанавливает заголовок и пересчитывает КС. КС у модуля в порядке, заголовок видимо тоже (иначе в логе служебки было бы "NO_DMCS", а не "DMCS", судя по документации)... Вас видимо смутило, что DMCS изменился? Вычитаю его вечером еще раз и проверю, меняется ли он между выключениями питания.
Восстановление P-list (AT_PDL) - вот это я тоже думал сделать перед пересчетом, но решил лишний раз не экспериментировать.
Не при чём. Это я глупость сморозил. Но очистить, я бы очистил. Просто для уверенности. Не так уж сильно на данные влияет.
Сдаётся мне, транслятор из-за 33-го модуля (P-List) не пересчитывается. Как бы его не пришлось чистить. Сохрани, на всякий случай его в листинге - Таблица дефектов->Просмотр P-List-> F2.
Это было давно и не правда.
Забыл почти все.
Ихмо:
Достаточно занулить P и G-листы (аппаратно) при этом очистится DMCS.
И пересчитать транслятор.
Отправить комментарий