Дали на ремонт комп... Сдуру включил в 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, на котором экспериментировал. Кушает некоторые лоадеры, но в них (в тех, что пробовал) не идет тест служебки, проверка служебки показывает нечитаемость большинства модулей, а также ПЗУ и оверлеев. Ресурсы с него все есть, но свой лоадер тоже почему-то не кушает... Ес-но, инфы на нем ценной нет, но теперь вдвойне аккуратен, выверяю каждый шаг.
Но у тебя все и так было нормально. Хотя 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 нужен, без него не работает.
http://www.acelab.ru/dep.pc/deudma.php
Может из-за них и данные побились? Хотя это ведь не P-list...
В документации к асе еще писали, что если есть дефекты, скрытые сразу в RZTBL, то после пересчета транслятора они будут перенесены на уровень AT_PDL, что теоретически может вызвать расхождения между изначальным транслятором и пересчитанным, но якобы на практике расхождения замечены не были. Как-то так...
Ну да, знаю я эти цены :) Я ж не профессиональный ремонтник.
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-а искать - если файл дефрагментирован - бестолковое дело.
Еще раз пересчитывал транслятор, уже с G-list'ом (т.е. заливал его перед пересчетом). Транслятор не изменился - по-прежнему 400+87 дефектов. По поводу транслятора еще решил спросить здесь: http://www.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 ... (дальше все нули до конца второго сектора).
Может кто подскажет, как винту команды посылать? Осмотрел его - доп. отладочных разъемов не обнаружил. Значит, через интерфейс? В сети по этому поводу инфы не нашел... Подскажите, кто знает...
В ini файле прописываешь команду. Её надо выполнить.
Потом в буфер грузишь данные (из двоичного файла длиной в два блока) и send buffer.
Что то типа такого. Давно HDDL не пользовался.
Боюсь толку один фиг не будет. Надо чтобы листинг p-listа "сейчас" совпадал с первым листингом, ещё до очистки.
Может быть попробовать заносить в p-list через g-list если lba лишних секторов известно.
Т. е. вручную добавить в g-list lba сектора, а затем переносом из g-lista в p-list.
Методом научного тыка или методом последовательных итераций можно попробовать подобрать lba так, чтобы попал на нужный сектор и трек. Это для тех секторов, которых не хватает в "новом" листинге. Правда долго и стрёмно.