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, на котором экспериментировал. Кушает некоторые лоадеры, но в них (в тех, что пробовал) не идет тест служебки, проверка служебки показывает нечитаемость большинства модулей, а также ПЗУ и оверлеев. Ресурсы с него все есть, но свой лоадер тоже почему-то не кушает... Ес-но, инфы на нем ценной нет, но теперь вдвойне аккуратен, выверяю каждый шаг.

Пасибо! Конечно, было бы не лишним. Тогда перед пересчетом очисти P-list & G-list - чтоб было как у меня. И после пересчета сравни новый транслятор со старым (модули U_LIST, RZTBL, AT_PDL, 33-й - в 33 прога по-идее не должна лезть, а у меня видишь лезла).

Но у тебя все и так было нормально. Хотя Tomset говорил, что нужно записывать "связанные" модули транслятора вместе - а у тебя получилось с одним только AT_PDL.

Цитата:
Смущает только то, что при пересчёте транслятора винт давал ошибку.
Есть еще один момент - у меня после очистки P-list & G-list сдвинулись некоторые модули (раньше UBA был один, теперь другой). Правда, они не налезают на другие, я подсчитал, и это вроде неважные модули - "Tbl_55AA" (3 шт.) и "OPTI - настройки SelfScan".

Давай еще сравним размеры 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

Цитата:
Проверил поверхность - появились бэды. Возможно это просто софт бэды и их можно объеразить.
А G-list случайно не забыл вернуть после пересчета транслятора? Может это как раз те бэды, которые были скрыты в G-list'е?

Может из-за них и данные побились? Хотя это ведь не P-list...

В документации к асе еще писали, что если есть дефекты, скрытые сразу в RZTBL, то после пересчета транслятора они будут перенесены на уровень AT_PDL, что теоретически может вызвать расхождения между изначальным транслятором и пересчитанным, но якобы на практике расхождения замечены не были. Как-то так...

Цитата:
Но стоит 70000р
Ну да, знаю я эти цены:) Я ж не профессиональный ремонтник.

Цитата:

А G-list случайно не забыл вернуть после пересчета транслятора? Может это как раз те бэды, которые были скрыты в G-list'е?

Может из-за них и данные побились? Хотя это ведь не 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...

В общем, буду экспериментировать дальше:)

Цитата:

Стал сливать данные. Процентов 10 фоток слить не удалось (в некоторых папках имена объектов представляли собой "кракозябры", некоторые файлы не прочитались - видимо, попали на бэды). Из скопированных примерно 25% - битые (не открываются). Итого спас примерно 65% фоток (если конечно те "кракозябры" - это только файлы, а не папки).

Кракозябры - это и есть смещение. Адресация не попадает на нужное место, туда где лежит сама директория. Попадает не на директорию, а куда нибудь.
Если разобраться в структуре 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 так, чтобы попал на нужный сектор и трек. Это для тех секторов, которых не хватает в "новом" листинге. Правда долго и стрёмно.

Отправить комментарий

Содержание этого поля является приватным и не предназначено к показу.
  • Разрешённые HTML-теги: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img>
  • You can use BBCode tags in the text. URLs will automatically be converted to links.

Подробнее о форматировании текста

Антибот - введите цифру.
Ленты новостей