1 Тема от Voldemar0 Отредактировано Voldemar0 (13-03-2019 11:43)

  • Voldemar0
  • Voldemar0
  • Участник
  • Неактивен

Тема: ОС Школьница, баги & глюки

Привет!

Случайно столкнулся с багом Школьницы, малозаметным на реале, но в эмуляторе вылез.
Задевает, как минимум, РАПИРу и ДОК. Может и копировщик тоже, семёрочные версии, до-ИКПшные.

Драйвер дисковода в этих системах ещё не имел отложенных операций и поддержки 840ки, возможно, когда его переписывали всё уже было исправлено. Но в оригинальных семёрочных версиях ошибка присутствует: драйвер зависает, если контроллер дисковода стоит в 6м слоте.

How Do They Do It?
Чтобы зря не гонять головку дисковода, в драйвере есть буфер для хранения текущих положений головок.
Буфер описан примерно так: u_int8_t drv_A[5], drv_B[5].
Т.е. два массива для первого и второго приводов по всем слотам.
Проблема в том, что слоты нумеруются от 1 до 6.
Нулевые элементы массива использованы под что-то вроде счётчиков попыток чтений (к ним обращение по абсолютным адресам), а элементы с 1 по 6 - для хранения фаз головок. Ну и дальше понятно - при работе с 6м слотом получаем index out of range.

Поскольку работаем с приводом A, то 6й слот попадает на B[0] - а там счётчик попыток поиска сектора.
Драйвер задаёт счетчик попыток, этим портит фазу. Затем пытается позиционировать голову, но так как фаза разрушена, голова едет не на нужный трек. Дальше делается попытка найти нужный сектор, его нет, пытается перетащить голову, но текущая фаза указана неверно, голова съезжает в сторону, а счётчик попыток обновляется, причем на значительную величину и никак не может достичь нуля (счётчик фаз считает в диапазоне [0..69], счётчик попыток - [4..-1]). Нет  нуля - нет ретрейса. Нет ретрейса - нет правильного позиционирования. Драйвер завис.

Интересно, что всё успешно работает если дисковод воткнуть в виртуальный 1-й слот, который даже не всегда распаивается на семёрке.

2 Ответ от Voldemar0 Отредактировано Voldemar0 (25-08-2019 12:40)

  • Voldemar0
  • Voldemar0
  • Участник
  • Неактивен

Re: ОС Школьница, баги & глюки

Ещё баг: если диск закрыт на запись и при этом выполняется какая-то модифицирующая операция (запись, удаление и т.д.) выводится сообщение "Диск закрыт на запись". Это хорошо.

Если потом вставить диск без защиты записи, следующая операция будет нормально выполнена.

Но вот что интересно: если после сообщения об ошибке записи вновь запросить немодифицирующую операцию (вывести каталог, например), то опять появляется сообщение "Диск закрыт на запись". Это плохо.

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

Простой тест: пытаемся записать на диск с защитой файл. Получаем ошибку.
Вставляем незащищённый диск, предварительно сделав его копию и пытаемся посмотреть его каталог.
Затем сравниваем копию и незащищённый оригинал. У меня модифицированным оказался VTOC 17/0 (изменился номер трека выделения) и VTOC 50/0 - один из свободных секторов отмечен как занятый (вероятно, там ОС пыталась создать новый Т/С список). Эти изменения были несущественны, но если бы я попытался, к примеру, удалить файл на защищённом диске, то вполне вероятно, на незащищённом бы что нибудь реално удалилось или открылось для записи или даже был бы решительно модифицирован один из секторов каталога.

Я не буду подробнее изучать этот баг, но его стоило добавить в копилку знаний.

3 Ответ от avivanov76

  • avivanov76
  • Участник
  • Неактивен

Re: ОС Школьница, баги & глюки

Неприятная бага. Но мне кажется, тут нет простого способа ее исправить. Аппаратно смена диска не проверяется. А программная проверка использует поле "номер тома", которое практически у всех дисков одинаковое, 254.

Тут, по хорошему, надо перед операциями записи пересчитывать хэш VTOC и сравнивать.

4 Ответ от Voldemar0

  • Voldemar0
  • Voldemar0
  • Участник
  • Неактивен

Re: ОС Школьница, баги & глюки

Тут два варианта:
1) Сбрасывать кеш самим драйвером флопика при любой ошибке.
2) Сбрасывать кеш в начале любой операции драйвером файловой системы.

Я бы делал первый вариант: от позволяет не вводить дополнительных операций в интерфейсе драйвера дисковода.

А вообще, логика работы кеширования команд очень плохо описана в доках даже на бейсик.
Хотя бы даже вот: что будет в случае ошибки в отложенных командах ? Как узнать конкретный адрес сектора,
в котором произошла ошибка обмена ?

А уж версия Школьницы для ИКП и девятки вообще никак не документирована (в смысле отличий от семёрки-140).