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
Пасибо! Конечно, было бы не лишним. Тогда перед пересчетом очисти P-list & G-list - чтоб было как у меня. И после пересчета сравни новый транслятор со старым (модули U_LIST, RZTBL, AT_PDL, 33-й - в 33 прога по-идее не должна лезть, а у меня видишь лезла).
Но у тебя все и так было нормально. Хотя Tomset говорил, что нужно записывать "связанные" модули транслятора вместе - а у тебя получилось с одним только AT_PDL.
Давай еще сравним размеры PCMX_PKR.EXE. У меня - 206 880.
Сколько кстати транслятор пересчитывается по времени?
P.S. То, что ты писал по поводу дефектов на месте 33 модуля - проверку поверхности я делал с самого начала - сбойные участки точно соответствовали группам модулей. Т.е. они приходились на те 7 битых модулей, ни больше, ни меньше (33-й был в порядке). Завтра проверю еще раз на всякий случай.
Очистил p-list и g-list, пересчитал транслятор. Power off/on. Данные, естественно, скукожились. ОС (в данном случае MS-DOS) видит, что есть логический диск, но он пустой и ошибка форматирования. Это нормально, и так и должно быть.
Заливаю взад 33-й модуль, пересчитываю транслятор, power off/on. Перезагрузка компа. Директории на максторе появились, но содержимое (не все правда, процентов 30 - нормальные) битое. Т. е. получается, что не всё правильно восстановилось, и что смещение где-то всё таки произошло. И произошло где-то посередине. По листингу p-lista можно даже прикинуть - где примерно.
В общем и целом...
Вливать 33-й модуль и пересчитывать транслятор, один фиг, надо. Но на этом мучения не кончатся. Придётся снимать образ и с ним работать - исключать это самое смещение. Теоретически это сделать можно. По крайней мере - для фотографий и для fat32.
FAT32 документирована и можно вычислить все необходимые смещения. А у jpg-ов известен заголовок. Можно найти начало jpg-а в файле образа.
Впрочем, это всё теоретические прикидки. Может есть какая специальная прога для этих случаев.
А насчёт программы PCMX_PKR.EXE... Здесь программа не при чём. Винт всё это сам делает в своём fw. Программа только запускает.
Ну и ещё.
Проверил поверхность - появились бэды. Возможно это просто софт бэды и их можно объеразить. М. б. именно из-за них и произошло смещение. Впрочем - это только мысли вслух.
Есть, DатаExtractor умеет создавать виртуальный транслятор FS.
Но и в нем не просто. Много ручной работы
А без программы с калькулятором, так вообще - повесишься. Особенно, если файлы фрагментированы.
Но стоит 70000р. К нему еще и контроллер PC3000-UDMA нужен, без него не работает.
acelab.ru/dep.pc/deudma.php
Может из-за них и данные побились? Хотя это ведь не P-list...
В документации к асе еще писали, что если есть дефекты, скрытые сразу в RZTBL, то после пересчета транслятора они будут перенесены на уровень AT_PDL, что теоретически может вызвать расхождения между изначальным транслятором и пересчитанным, но якобы на практике расхождения замечены не были. Как-то так...
Может из-за них и данные побились? Хотя это ведь не P-list...
G-list - в данном случае без разницы. У меня g-list нулевой и он на смещение не влияет.
Не писал долго, т.к. занят был...
Прогресс есть! Залил родной 33, пересчитал транслятор (без сообщений об ошибках). Пересчет шел, кстати, около 50 мин (винт на 30 гиг). Глянул P-list. В родном было 487 дефектов в 1-ом блоке + 71 во 2-ом. После пересчета - только первые 487 дефектов (в 1-ом блоке - 400, во втором - 87).
Загрузил DOS - увидел 2 раздела (вроде там FAT32)! Стал сливать данные. Процентов 10 фоток слить не удалось (в некоторых папках имена объектов представляли собой "кракозябры", некоторые файлы не прочитались - видимо, попали на бэды). Из скопированных примерно 25% - битые (не открываются). Итого спас примерно 65% фоток (если конечно те "кракозябры" - это только файлы, а не папки).
Сейчас хочу снять образ с помощью dd_rescue и вытянуть что-нибудь с него. Сначала скормлю его R-studio, потом попытаюсь вытянуть все файлы в кучу по JPEG-заголовкам (сдвиг по идее не влияет, т.к. каждый файл будет искаться заново). Пока, правда не получилось. Взял какой-то старый live-cd, там dd_rescue работает около минуты и вылетает с segmentation fault. Попробую линукс с винта (и другой дистрибутив) - может это влияет.
Еще планирую вернуть родной G-list. Пересчитать транслятор с родным G-list'ом (здесь я пересчитывал с пустым G-list'ом, вряд ли это влияет, но попробовать стоит). Наконец, попробую добавить 71 дефект ручками через меню аси.
Все-таки интересно, почему я не получил оригинальный транслятор... Явно есть ограничение на кол-во дефектов в блоке (400) - в результате 487 дефектов были размазаны по 2 блокам. Но почему 71 дефект не был добавлен во 2-ой блок, ведь 87+71 - до 400 еще далеко?.. И где эти ограничения - в прошивке винта или в асе?.. Если конечно еще AT_PDL соответствует 33-му модулю, ведь этот список дефектов берется именно с 33-го, а не с AT_PDL...
В общем, буду экспериментировать дальше
Кракозябры - это и есть смещение. Адресация не попадает на нужное место, туда где лежит сама директория. Попадает не на директорию, а куда нибудь.
Если разобраться в структуре FAT32 то можно вычислить, на сколько секторов идёт промах и это кол-во секторов выкусить.
65% фоток спас - свезло.
А по заголокам jpg-а искать - если файл дефрагментирован - бестолковое дело.
Снял образ dd_rescue, скормил R-Studio. Прогресса пока не обнаружил. Попробую еще несколько вариантов снятия образа.
Еще раз пересчитывал транслятор, уже с G-list'ом (т.е. заливал его перед пересчетом). Транслятор не изменился - по-прежнему 400+87 дефектов. По поводу транслятора еще решил спросить здесь: ihdd.ru/forum/translyator-pereschitan-ne-polnostyu-t9171.html
P.S. Проблема с запуском dd_rescue была в том, что я обращался к подмонтированному разделу, а прога ведь работает с блочным устройством (в моем случае /dev/sdb5). Для экономии времени запускал с пар-ром -B 51200, т.е., как я понял, образ получился неточным в областях бэдов.
Поднимаю старую тему
Мне посоветовали еще вот что:
Попробуйте "вручную" подать команду пересчета транслятора сначала 0000 00 00 00 ff ff a0 c0 винт поднимет DRQ, ну и отправляем ему 2 сектора 59 A6 01 0A 00 00 ... (дальше все нули до конца второго сектора).
Может кто подскажет, как винту команды посылать? Осмотрел его - доп. отладочных разъемов не обнаружил. Значит, через интерфейс? В сети по этому поводу инфы не нашел... Подскажите, кто знает...
HDDL -ем.
В ini файле прописываешь команду. Её надо выполнить.
Потом в буфер грузишь данные (из двоичного файла длиной в два блока) и send buffer.
Что то типа такого. Давно HDDL не пользовался.
Боюсь толку один фиг не будет. Надо чтобы листинг p-listа "сейчас" совпадал с первым листингом, ещё до очистки.
Может быть попробовать заносить в p-list через g-list если lba лишних секторов известно.
Т. е. вручную добавить в g-list lba сектора, а затем переносом из g-lista в p-list.
Методом научного тыка или методом последовательных итераций можно попробовать подобрать lba так, чтобы попал на нужный сектор и трек. Это для тех секторов, которых не хватает в "новом" листинге. Правда долго и стрёмно.
Отправить комментарий