» Samsung (Самсунг). Ремонт и восстановление накопителей. III

плата трайдент 2
p/n 4015
hd321kj
t166s

посмотрел по табличкам - есть

cp12b14c.dn cp12b14c.dn5 и тд

но родной комплект, вроде как другой

FSI FT01R001.001 cp1n414BHD321KJ

- так какой комплект правильный для такого винчестера?
заранее спасибо за ответы

вроде как такой же cp1n414B встречается (единственная ссылка гугла)

http://www.rom.by/forum/Samsung_HD321KJ_stuchit?page=1

[off]
NiTr0

Цитата:

Вместо 1 слова снова сливать весь блок в 128-192к данных? Оптимальненько, да...

Какое еще одно слово или 128Кб. ROM на Samsung'aх получают блоками по 200/400/800 байт.
Это намного оптимальней,чем держать в памяти огромный буффер и вставлять туда ваше потерянное слово.
Или вы считаете что пословный прием "оптимальный",несмотря на издержки с генерацией адреса в команде ?

Цитата:

Ну в приведенной в топике софтине разор полученного по ком-порту занимал 5-10 секунд...

В какой софтине ? Я не верю что можно получить ROM на Samsung за 5-10 секунд. Даже подняв BaudRate.
Цитата:

Только оптимальность кода сомнительна.

Такое ощущение что вы говорите о каком то сферическом коне в вакууме.
Любой вендор софт сделан именно на скриптовом движке. (хоть Gemini,WCube,хоть Trexx и питоновые скриты на Seagate). Не нужна надуманная борьба за такты. (за которые,разворачиванием циклов и отказом от использования условных переходов ,приходится платить размером кода )

Цитата:

Зато скорость исполнения на 2 порядка выше чем у скриптовых языков...

Нужна острожность со словами. На 2 порядка,означает "в 100 раз". Чего естественно нет.
А скорость написания программы вы учитываете ?
Ну за сколько вы напишете "прг." которая находит все контейнеры WD-модулей (т.е такие модули,которые содержат в себе другие ) ? Воот. А скриптновые языки позволяют написать такое за час.+ сама такая "программа" никакой ценности как самостоятельный экзешник не имеет,хоть в 15
раз он эффективней,хоть в 500. Это чисто щуп. И сколько он в работе значения не имеет.

Цитата:

Если знаешь 3-4 языка - на освоение нового на уровне программирования со шпаргалкой уходит от 2-3 дней до недели, в зависимости от его похожести/непохожести на другие...

Я программирую на REXX и ассемблере несколько лет. Не могу сказать,что я их знаю. Поэтому про
неделю и шпаргалку это слишком оптимистично.

[/off]



Добавлено:
USSTO
Пожалуйста

alpham100
Именно 4015 не нашёл, а по 4014 так :

Цитата:

P/N___Family__SCCODE________BBIN___________HTCODE_____SECBICODE_____SCRBIN
4014__T166S__CR12W12S.DN__CR12R12C.DN__CR12R12C.DN5__CT12R22C.DN5__cr13c12m.dn4
для HD321KJ_________________CP12T14C.DN__CP12T14C.DN5__CM12T24C.DN5__CP12K14M.DN4

Цитата:

вроде как такой же cp1n414B встречается

Есть и cp1n414c.dn5...Это бурн-код сам.

Цитата:

Я не верю что можно получить ROM на Samsung за 5-10 секунд. Даже подняв BaudRate.

На стандарте 57600 более минуты, до 4-5 мин. Конечно зависит от размера рома и скорости чтения. Но не секунды. Мож NiTr0 имел ввиду время сбора уже считанных блоков в файл ?

Michael99

Цитата:

Есть и cp1n414c.dn5...Это бурн-код сам.

в каком комплекте такой файл встречается?

p.s. смотрел служебку с такого же винчестера только p/n 4024
а вот комплект в FIT - как я выше указал комплект
а тут наверно все же другой

Цитата:

в каком комплекте такой файл встречается?

В заводском. Для T166S HD321KJ.


Добавлено:

Цитата:

а вот комплект в FIT

В FIT никакого указания на бурн-комплект не может быть, т.к. это таблица модулей СА. А вот в FSI указывается название бурна с которым он проходил на заводе.

Добавлено:

Цитата:

смотрел служебку с такого же винчестера только p/n 4024

И для 4024

Цитата:

P/N___Family__Model_____SCCODE_______BBIN_________HTCODE________SECBICODE_____SCRBIN
4024__T166S__HD321KJ__CR12W12S.DN__CP12T14C.DN__CP12T14C.DN5__CM12T24C.DN5__CP12K14M.DN4

alpham100
Да и просите у Миши родный бурн. У других не найдете. А родный мэйн можно
определить, слив флешку. А если и оверлей слить - можно склепать. Только
зачем ? наверняка найдется там, где и бурн...

Цитата:

А родный мэйн можно
определить, слив флешку.

Ну версия мэйна роли не играет. Для всех HD320KJ, HD321KJ мэйн одинаков и от PN не зависит.

[off]
tametung

Цитата:

Какое еще одно слово или 128Кб. ROM на Samsung'aх получают блоками по 200/400/800 байт.
Это намного оптимальней,чем держать в памяти огромный буффер и вставлять туда ваше потерянное слово.

Оптимальнее в чем? В скорости? Сомневаюсь. А рассуждать о "огромном буфере" на целых 128кБ, используя интерпретируемый язык, интерпретатор которого под свои нужды отжирает эдак с несколько мегабайт - некошерно как-то...


Цитата:

Или вы считаете что пословный прием "оптимальный",несмотря на издержки с генерацией адреса в команде ?

Прием блоком максимальной длины + "добирание" потерянных слов/строк по факту будет оптимальнее, не?


Цитата:

В какой софтине ? Я не верю что можно получить ROM на Samsung за 5-10 секунд. Даже подняв BaudRate.

Речь шла не о получении, а о постобработке блока данных.


Цитата:

Любой вендор софт сделан именно на скриптовом движке. (хоть Gemini,WCube,хоть Trexx и питоновые скриты на Seagate). Не нужна надуманная борьба за такты. (за которые,разворачиванием циклов и отказом от использования условных переходов ,приходится платить размером кода )

Вендор софт использует скриптовый движок для вызова неких готовых процедур. Но никак не сделан на скриптовом движке. Это - две больших разницы.


Цитата:

Нужна острожность со словами. На 2 порядка,означает "в 100 раз". Чего естественно нет.

Именно это я и имел ввиду. Разница по скорости между нативным кодом и интерпретируемым байт-кодом (ява и иже с ними) - порядок, между нативным кодом и интерпретируемым скриптом - 2 порядка.


Цитата:

Ну за сколько вы напишете "прг." которая находит все контейнеры WD-модулей (т.е такие модули,которые содержат в себе другие ) ? Воот. А скриптновые языки позволяют написать такое за час.+ сама такая "программа" никакой ценности как самостоятельный экзешник не имеет,хоть в 15
раз он эффективней,хоть в 500. Это чисто щуп. И сколько он в работе значения не имеет.

Никто не спорит, что интерпретируемые языки проще. Потому их и пользуют для прототипирования. Но готовый продукт на них будет весьма тормозным.


Цитата:

Я программирую на REXX и ассемблере несколько лет. Не могу сказать,что я их знаю. Поэтому про
неделю и шпаргалку это слишком оптимистично.

Изучение перла в объеме, достаточном для понимания и модификации кода биллинговой системы под определенные реалии заняло у меня дня 3 к примеру... Да, си-подобный он конечно, но со своими особенностями и спецификой (чего только хеши стоят)...
[/off]

[off]
NiTr0

Цитата:

А рассуждать о "огромном буфере" на целых 128кБ, используя интерпретируемый язык, интерпретатор которого под свои нужды отжирает эдак с несколько мегабайт - некошерно как-то...

Интерпретатор REXX идущий в поставке IBM'овской PCDOS имеет размер 81166 байт.
И из-за ограничений (сегментная адресация,расположение и управление памятью самой DOS) ну никак не может отжирать "под свои нужды" мегабайты.


Цитата:

Прием блоком максимальной длины + "добирание" потерянных слов/строк по факту будет оптимальнее, не?

Нет не будет. Например ROM на Тoshiba 512Кб. Т.е только для хранения поступивших и возможно искаженных данных нужен массив больше мегабайта.А скорость 9600,т.е
затраты на преобразование будут совершенно ничтожными,чем на само получение даты.


Цитата:

Речь шла не о получении, а о постобработке блока данных.

Ну если 5-10 секунд тратит С программа,то ну егонах такое С. Я писал парсер на асме-только запустил-уже готово. Т.е секунда,и это не смотря на вашу выдуманную оптимальность "умного компилятора"


Цитата:

Вендор софт использует скриптовый движок для вызова неких готовых процедур. Но никак не сделан на скриптовом движке. Это - две больших разницы.

А какая разница как он сделан,если для работы используется именно скриптовый движок ? Если бы программисты написали на интерпретируемом Forth,то и процедуры и движок могли бы быть написанны именно на интерпретируемом языке.
А "готовые процедуры" и играют роль тех самых необходимых вставок о которых я говорил выше.


Цитата:

между нативным кодом и интерпретируемым скриптом - 2 порядка.

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


Цитата:

Изучение перла в объеме, достаточном для понимания и модификации кода биллинговой системы под определенные реалии заняло у меня дня 3 к примеру...

Ну значит вы дней за 5 сможете разобраться с приемом данных по компорту,и показать
нам сверхбыструю прг. с битмапом и т.п,да ?
[/off]

вечер добрый

винчестер hd321kj t166s
смарт после бурна - не читается
наверно или из за бурна что прошел с led 00 e000

ну или просто нужно инициализировать смарт

а как это сделать не пойму

те что есть утилиты хутиль шт 15 версий

пишут про не совместимое семейство

ES-Tool 3.01
нет раздела инициализация смарта
только включить и выключить

вопрос снят решена проблема

взял версию с http://files.hddguru.com/download/Software/Samsung/HUTIL/

hutil210.rar
HUTIL v2.10 FULL (SVC.CFG) - Config Made By FaNaTyK for HddGuru.com --Utility to test and repair Samsung HDDs.

[off]
tametung

Цитата:

Интерпретатор REXX идущий в поставке IBM'овской PCDOS имеет размер 81166 байт.
И из-за ограничений (сегментная адресация,расположение и управление памятью самой DOS) ну никак не может отжирать "под свои нужды" мегабайты.

И что на этом интерпретаторе-то можно написать? Разбор многомегабайтного модуля осилит?


Цитата:

Нет не будет. Например ROM на Тoshiba 512Кб. Т.е только для хранения поступивших и возможно искаженных данных нужен массив больше мегабайта.А скорость 9600,т.е
затраты на преобразование будут совершенно ничтожными,чем на само получение даты.

Вы только по медленному ком-порту с каплями данных работаете?


Цитата:

Ну если 5-10 секунд тратит С программа,то ну егонах такое С. Я писал парсер на асме-только запустил-уже готово. Т.е секунда,и это не смотря на вашу выдуманную оптимальность "умного компилятора"

Читайте внимательнее. Речь шла о программе на VB.


Цитата:

А какая разница как он сделан,если для работы используется именно скриптовый движок ?

Огромная разница. Все операции с большими объемами данных - на компилируемом языке, и готовые блоки вызываются из скрипта на сотню-полторы строк, затратами на парсинг которого можно пренебречь.


Цитата:

А "готовые процедуры" и играют роль тех самых необходимых вставок о которых я говорил выше.

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


Цитата:

Программа на С и программа на скриптовом языке,получат данные из ком-порта за примерно одно и тоже время.
И ни о каком порядке при сравнении производительности ,речь вообще не может идти.
Мне не надо вычислять стомиллиардное простое число или отрисовывать экран.

У вас все задачи ограничиваются работой с медленным ком-портом? А разбор дефект-листа эдак на несколько десятков тысяч дефектов если взять? С перегруппировкой и объединением их в треки?


Цитата:

Ну значит вы дней за 5 сможете разобраться с приемом данных по компорту,и показать
нам сверхбыструю прг. с битмапом и т.п,да ?

Прием данных по ком-порту я писал еще лет 8 назад, будучи студентом. Голый WinAPI, включая создание диалогов... Если найду время - может и наваяю чего, благое дело - задумываюсь о кросс-платформенной софтине хотя бы с работой по терминалу, надоело на круглосуточно работающем тазике под вайном стмемом рыбок мучить...
[/off]
alpham100

Цитата:

ну или просто нужно инициализировать смарт

а как это сделать не пойму

В кубе:
smart (0xde, 0, 1)

[off]
NiTr0

Цитата:

И что на этом интерпретаторе-то можно написать? Разбор многомегабайтного модуля осилит?

Ну а почему нет ? Просто писать скрипт придется с учетом ограниченности ресурсов,используя seek'a и чтениея по N-байт.Ну а как работают Gemini и Trexx ?
Кстати это хороший пример того где можно использовать вставки. Под DOS-Rexxом приходится извращаться. (тело скрипта содержит данные,из которых образуется исполняемый файл,который запускается выполняет -работу и передает результаты опять
черз файл. Это согласитесь не очень удобно. Но например позволяет читать трэк на семействах .11 и выше за секунду-полторы.


Цитата:

Огромная разница. Все операции с большими объемами данных - на компилируемом языке, и готовые блоки вызываются из скрипта на сотню-полторы строк, затратами на парсинг которого можно пренебречь.

Хм. Откуда это сотню-полторы строк,про что вы говорите ? Только main cкрипт на трексе содержит примерно 23000 строк.
И насчет огромной разницы. Ну вот я писал скрипт находящий все пары изменившихся файлов. Например считали модули до скана и после. Что поменялось ? При работе скрипта открывается ,считывается и сравнивается больше 800 файлов. Время работы ну пусть 30 секунд. Это как, оч. долго ? Либо скрипт нахождения какой-то строки (например hex.) во всех 400+ модулях ВД. Тоже- ну пусть минута. И притом что у REXX'a есть оч. неприятные моменты при работе с бинарниками.
Так что все вполне за разумное время.

p.s.Все-завязываем.Никто никому ничего не докажет.Разбегаемся при своих.
[/off]

NiTr0
спасибо про вкуб и смарт - записал в памятку

Цитата:

разбор дефект-листа эдак на несколько десятков тысяч дефектов если взять? С перегруппировкой и объединением их в треки?

В самсунговских S-листах такое только, и до сотен тысяч. Но никто не группирует в S-листе записи о дефектах в треки. Да и в Р-лист ВД этого не нужно делать. Это я вам как практик говорю (не программер). Это просто лишено смысла. А вот в Г-листах это очень необходимая вещь, но там не бывает десятков тысяч дефектов.

tametung

Цитата:

Ну а почему нет ? Просто писать скрипт придется с учетом ограниченности ресурсов,используя seek'a и чтениея по N-байт.Ну а как работают Gemini и Trexx ?

TREXX пока в руки не попадал, попадет - гляну, но я более чем уверен, что он работает в protected mode... А перезапись модуля по каплям - весьма накладное занятие...


Цитата:

Под DOS-Rexxом приходится извращаться. (тело скрипта содержит данные,из которых образуется исполняемый файл,который запускается выполняет -работу и передает результаты опять
черз файл

Ну и смысл таких плясок с бубном?


Цитата:

И насчет огромной разницы. Ну вот я писал скрипт находящий все пары изменившихся файлов. Например считали модули до скана и после. Что поменялось ? При работе скрипта открывается ,считывается и сравнивается больше 800 файлов. Время работы ну пусть 30 секунд. Это как, оч. долго ?

Да, очень долго. Реально время сравнения будет сопоставимо со временем копирования с одного места в другое.


Цитата:

Либо скрипт нахождения какой-то строки (например hex.) во всех 400+ модулях ВД. Тоже- ну пусть минута.

Тоже очень долго. grep к примеру на 4МБ файле отрабатывает 1-2 секунды...

Michael99

Цитата:

Да и в Р-лист ВД этого не нужно делать. Это я вам как практик говорю (не программер). Это просто лишено смысла.

Смысл есть, хоть и небольшой (к примеру п-лист почти забит, а в него надо впихнуть еще дефектов).

[off]
NiTr0

Цитата:

Тоже очень долго. grep к примеру на 4МБ файле отрабатывает 1-2 секунды...

проверил. (под Win98) Запустил скрипт искать строку "Model" в папке с 413 файлами. (2 из которых 4Мб.) результат 11 секунд. (найдено 4 вхождения,естественно с офсетами)На бинарной строке 4704h на тех же 413 файлах, 2400+ вхождений за 7 секунд.

Цитата:

Да, очень долго. Реально время сравнения будет сопоставимо со временем копирования с одного места в другое.

? я не думаю что 11 или 7 секунд это очень долго.

Цитата:

Ну и смысл таких плясок с бубном?

так читайте не только себя,о вставках слышали я говорил ? (вот их и нет возможности -сделать на прямую.Таков язык. А в бэйсике это -легко(встроено))

Цитата:

А перезапись модуля по каплям - весьма накладное занятие...

не по каплям,а сколько позволяет размер сегмента. (кстати и у самого винта есть предельный размер блока обслуживаемый за одну команду и даже если я читаю все модули несколько минут (не засекал),то меня (лично) это никак не напрягает. Это не ловля блох,можно обойтись без спешки.
p.s
кстати никакой необходимости группировки в трэки в GList нет. Винт сам это прекрасно делает. (и именно поэтому иногда требуется remerge)


Цитата:

но я более чем уверен, что он работает в protected mode..

Да в защищенном. Но для записи файла,он использует ф-цию DOS,в которой размер сбрасываемого задается через рег.СX
и не может превышать теже 64 Кб. (аналогично и по чтению).
[/off]

NiTr0
Что надо сваять на бейсике для примера? , ато у вас споры ни как не закончаться

USSTO

Цитата:

Что надо сваять на бейсике для примера?

В PC3K не релизован (или может не знаю как сделать ? если только из редактирования листинга дефектов сохраненных как текст ?) дополнение диапазоном секторных дефектов. Т.е например на цилиндрах N,N+1,...N+К по голове M,нужно вставить cектора [I;J]
Будет полезно.

Цитата:

Смысл есть, хоть и небольшой (к примеру п-лист почти забит, а в него надо впихнуть еще дефектов).

Вы не говорите про какой-то теоретический смысл, а возьмите на практике Самсунг, сгруппируйте в S-листе энную кучу дефектов в треки, а потом посмотрите на поляну простой Викой. И результат - зелень в каждой зоне по всему винту из-за внесённого сдвига трансляции в ParamDM. Сам сколько раз экспериментировал с F-сериями.

вопрос про терминал и шторм

один винт hd082GL

бурнился, застрял на 260 степе и выдал led 48
хотел бурн допихать, но его втул не понимает

нужно через терминал поменять несколько байтов - что бы бурн продолжился

а именно

DBG>RM 8 0 1
W:006100 4146 4C49 2020 2020 2020 2020 454A 2020 FAIL
W:006108 0000 0000 0000 0000 0000 0000 0000 0000


а нужно

434F 4E54 2020 2020 2020 2020 4A45 2020

наш коллега когда то постил тут

RM <номер модуля> <номер сектора модуля> <кол-во секторов> - чтение сектора модуля.
К примеру, RM 4 0 1 - прочитать 0-й сектор 4-го модуля (М-лист), результат вывести на экран
DW <адрес "W-памяти"> [кол-во слов] - отобразить указанное кол-во слов по адресу в памяти (по умолчанию - 8 слов, 16 байт)
MW <адрес "W-памяти"> <слово 1> [слово 2] ...... - записать в память данные
WM - запись модуля, параметры аналогично RM.


ENG>RM 8 0 1
W:006100 4146 4C49 2020 2020 2020 2020 454A 2020
W:006108 0000 0000 0000 0000 0000 0000 0000 0000
W:006110 0006 0000 0100 0400 0001 0000 0000 0100


непонятно с момента - какой синтаксис записи определеных байт в модуль

ENG>MW 006100 434F 4E54 2020 2020 2020 2020 4A45 2020
E:0002 - Inv Prm
ENG>


Самое смешное, получилось, только как написал сюда
и наверно из за глюков в терминале? c 3 раза получилось


ENG>MW 006100 434F 4E54
E:0002 - Inv Prm

DBG>MW 006100 434F 4E54
E:0001 - Inv Cmd

DBG>MW 006100 434F 4E54
DBG>

[off]
tametung

Цитата:

Запустил скрипт искать строку "Model" в папке с 413 файлами. (2 из которых 4Мб.) результат 11 секунд. (найдено 4 вхождения,естественно с офсетами)На бинарной строке 4704h на тех же 413 файлах, 2400+ вхождений за 7 секунд.

Для чистоты эксперимента запустите это же с рамдиска, и запустите потом стандартный grep. сравните скорость


Цитата:

я не думаю что 11 или 7 секунд это очень долго.

на 10 МБ - относительно недолго (на каком проце к слову?), на 100 МБ скажем - уже долго..


Цитата:

так читайте не только себя,о вставках слышали я говорил ? (вот их и нет возможности -сделать на прямую.Таков язык. А в бэйсике это -легко(встроено))

Условно легко. При этом надо думать как бы не вылезти за границы отведенной памяти и т.п. прелести...


Цитата:

не по каплям,а сколько позволяет размер сегмента.

= по каплям...


Цитата:

Да в защищенном. Но для записи файла,он использует ф-цию DOS,в которой размер сбрасываемого задается через рег.СX
и не может превышать теже 64 Кб. (аналогично и по чтению).

Никто не будет каждую операцию удаления дефекта\перегруппировки дефектов дергать файлы (а если скажем надо удалить/сгруппировать 100 дефектов? для каждого удаленного из списка дефекта подтягивать весь хвост вверх?). Это все делается в памяти, и потом модуль сбрасывается на диск/пишется в винт.
[/off]

alpham100
006100 не обязательно нулями добивать впереди...

NiTr0
понято, спасибо,
самое не приятное, что команды в терминале с 2-4 раза отрабатывают
и как например в листинге команд видно

ps бурн за 10 минут так и не стартовал, после изменения заголовка, и рестарта по питанию

пока поставил бурниться с начала,
пнув бурн в терминале командой ( пошел степ 1 и тд)

[off]
NiTr0

Цитата:

Для чистоты эксперимента запустите это же с рамдиска, и запустите потом стандартный grep. сравните скорость

Cкачал Windows Grep 2.3. 392 файла (ACE *.rpm) он обрабатывал 12 секунд. (искал строку "MODEL"). под ХP 2Gb mem CPU E2200. Мой скрипт я гонял на Win98/ZOC4 Celeron 633 128Мб.
Как искать бинарные последовательности в WinGrep так и не понял.
К тому же сам файл грепа занимает 1.1 Мб на диске (и использует для работы 10Мб).Ппц,какое
эффективное С. :lol

Цитата:

на 10 МБ - относительно недолго (на каком проце к слову?), на 100 МБ скажем - уже долго..

на наборах из 40Мб.

Цитата:

для каждого удаленного из списка дефекта подтягивать весь хвост вверх?

А откуда я знаю,как вы сортируете ? Речь шла о чтении и записи файлов (а оно одинаковое
и для протектед)
[/off]

[off]
tametung

Цитата:

Cкачал Windows Grep 2.3. 392 файла (ACE *.rpm) он обрабатывал 12 секунд. (искал строку "MODEL"). под ХP 2Gb mem CPU E2200. Мой скрипт я гонял на Win98/ZOC4 Celeron 633 128Мб.
Как искать бинарные последовательности в WinGrep так и не понял.
К тому же сам файл грепа занимает 1.1 Мб на диске (и использует для работы 10Мб).Ппц,какое
эффективное С. :lol

нетбук с линем, первая попавшаяся папка с файлами (тимвьювер 7, 22 с копейками метра). Grep по всем файлам на 2 проход (когд все в кеш поднялось с диска) по строке test отрабатывает менее секунды, причем - намного менее (на глаз - эдак 0.1 сек). Проц - С60. Думаю, разница налицо


Цитата:

А откуда я знаю,как вы сортируете ? Речь шла о чтении и записи файлов (а оно одинаковое
и для протектед)

Вы же говорили о работе с файлами по кускам. Т.е. любое удаление дефекта - перелопачивание всего файла по кусочкам в 64к... Что не есть эффективно ни разу.
[/off]

Добавлено:
alpham100

Цитата:

самое не приятное, что команды в терминале с 2-4 раза отрабатывают

Сразу отрабатывают. Может терминал мусор сыпет еще?

NiTr0

вот с 3 раза сработал - мусора никакого
( на ENG \ DBG не обращай внимание - раз 10 пробовал, криво с листинга скопировал только это)


ENG>MW 006100 434F 4E54
E:0002 - Inv Prm

DBG>MW 006100 434F 4E54
E:0001 - Inv Cmd

DBG>MW 006100 434F 4E54
DBG>

заметил еще - на пару винтах - после неудачной загрузки дн\дн3 - когда бурн не пошел
при попытки залить дн - винт в ENG> не выходит после включения
зато как ткнеш "энтер" - сразу в

ENG>SRV>

бурн - на таких винтах не как не запускается не командой в терминале,
не исправив заголовок BISP

может конечно платы битые, хотя винт хочет очень именно родной комплект...

p.s. про очистку служебной зоны не SA - форматером

находил вот такое

" ... либо - втулом, запустив search micro defects тест на 0-м цилиндре (или для надежности - с 0 по, скажем, 16 - а если время не жмет, то и с 0 по 64)..."

такое кто нибуть пробовал?

[off]
NiTr0

Цитата:

Думаю, разница налицо

Сколько там файлов ? И на второй проход (когда все поднялось в кэш) эксперимент не чистый.
A размер грепа и расход памяти забыли прокоментировать (как и поиск бинарной строки) ?
+ я говорил о своем скрипте ( в 140 строк),а вы о чужом Grep. Какие результаты дает ваша собственная
процедура поиска ?


Цитата:

Т.е. любое удаление дефекта - перелопачивание всего файла по кусочкам в 64к... Что не есть эффективно ни разу.

я вообще не говорил о удалении дефектов. ,а говорил про то что трекс работает в DOS. (и у него вроде нет ф-ции удаления дефекта из PList)
[/off]

Да ребята NiTr0 и tametung Вашу б энергию да в мирное русло глядиш и сотворили б что-то путнее .

CASIKO3162

Цитата:

и сотворили б что-то путнее .

что например ?

tametung
Например чтение и запись ПЗУ на TOSHIBA-х типа MK7559GSXP и подобных.
По интерфейсу и по терминалу.

О, как...Вам же Владимир уж ответил - надо экспериментить. Ну так займитесь... Или просто ждите, когда по тошкам начнут вываливать в открытый доступ.