_ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _
From : Alex Korchmar 2:5020/28.101 01 Dec 98 15:26:16
Subj : scsi bug, или снова о девочках
________________________________________________________________________________
Hi All!
интересно, почему только я наступаю на подобные грабли?
Хотите грабель? Их есть. [сразу скажу, что все нижеописанное
бывает исключительно у владельцев ядра 2.1. С 2.0 все будет работать]
Лабораторная работа номер два.
Цель работы: на практике убедиться, что a) обработчик ошибок вообще
не отвечает своему назначению - т.е. неспособен ничего толком
обработать; b) что линуксовый скази - суксь.
Приборы и материалы: тормозной стриммер из лабораторной номер один,
отдельный scsi-контроллер aha1540 специально для этого стриммера (
в идиотской надежде отделить в изолированной среде мух от котлет).
Теоретическая часть.
Как известно, где-то к 2.1.52, был существенно перепахан mid level
scsi код. Мне известны два отличия нового кода от старого:
повыброшено большое количество раскиданых по коду 'cli();' и
изменен интерфейс обработки ошибок - вместо преферансных "в морду и аборт"
появились отдельные точки входа в low level драйверах для разных уровней
- отдельная команда, отдельное устройство, все устройства, хост.
Похоже, однако, этим дело не ограничилось, и по дороге насажали новых ошибок.
Факультативный элемент.
Если вы можете обойтись без осталных скази дивайсов - вкомпилите в ядро
код для скази-логгинга. Если не можете - не вкомпиляйте, поскольку этот
код не умеет избирательно привязываться к одному хосту и все интересное
будет утоплено в нормальной работе вашего винчестера (причем именно
таким образом, чтобы было невозможно легко разделить информацию от
разных хостов).
Практическая часть.
tar -tvf /dev/nst0
[skip - похоже, фокус связан именно с чтением filemark (действительно, долгая
операция), поскольку все всегда происходит на последних килобайтах в последнем
файле ]
Dec 1 02:47:37 alx kernel: aha1542_queuecommand: dev 5 cmd 05 pos -1 len 6
aha1542_queuecommand: dumping scsi cmd:05 00 00 00 00 00
Dec 1 02:47:37 alx kernel: aha1542_queuecommand: dev 5 cmd 1a pos -1 len 12
aha1542_queuecommand: dumping scsi cmd:1a 00 00 00 0c 00
Dec 1 02:47:37 alx kernel: aha1542_queuecommand: dev 5 cmd 08 pos 64 len 32768
aha1542_queuecommand: dumping scsi cmd:08 01 00 00 40 00
Dec 1 02:48:08 alx last message repeated 46 times
[нормально, читаем]
Dec 1 02:48:37 alx last message repeated 77 times
[пока все в полном порядке. близится конец архива. И вдруг:]
Dec 1 02:48:38 alx kernel: aha1542.c: Trying device reset for target 5
[дивайс - медленный scsi-1 стриммер, поэтому он не понимает, чего от него
хотят - он занят, читает filemark, и за пять секунд ничего просто не
успевает переварить.]
Dec 1 02:48:56 alx kernel: Sent BUS RESET to scsi host 1
[ядерный обработчик такие мелочи не беспокоят, таймауты не настраиваются -
оглоблей по балде - хряп!]
Dec 1 02:49:06 alx kernel: st0: Error with sense data: extra data not valid
Current error st09:00:
sns = 70 6
Dec 1 02:49:06 alx kernel: Raw sense data:0x70 0x00 0x06 0x00 0x00 0x00 0x00
0x06 0x00 0x00 0x00 0x00 0x00 0x00
[нормальное состояние после ресета, не так ли? (не тратьте время - это "Unit
attention".)
Hо нет - только не для ядра линукса. ]
tar: /dev/nst0: No such device or address
[обработчик ошибок свалился на "disable device". Подчеркиваю - по
собственной глупости. Более того, он просто не мог после ресета никуда
больше свалиться, если не умеет понимать, что там будет именно error.
rmmod st; insmod st чудесным образом возвращает дивайс к жизни без
каких-либо сообщений об ошибках. Естественно - теперь-то inquiry пройдет.]
Факультативная практическая часть (приводится в пересказе, поскольку
логи отсутствуют. Поверьте или проверьте. Hе вздумайте, конечно, писать
сислогом на _сказевый_ винчестер - дыру прогрызете и ничего толком не
получите. О том, что все это дергается с дефолтовым левелом, а не с
KERN_DEBUG, упоминать излишне - авторам было некогда, их такие мелочи
не беспокоили.)
echo "scsi log timeout 7" > /proc/scsi/scsi
echo "scsi log error 7" > туда же
имеем: _никаких_ таймаутов в указанный момент не экспайрилось. Просто,
как чортик из табакерки, выскакивает кернельный трид, отвечающий за
обработку ошибок (еще раз отмечу: _нет_ тут никакой ошибки, она в
деревянной голове того кто писал код, точнее, испоганил уже написанный)
- и давай ее обрабатывать. А поскольку делать этого не умеет - то
результат из основной практической части.
Вопросы для самостоятельного изучения:
каким образом управление попадает на scsi_error_handler и как это
отследить?
Если через таймаут - каким образом ему удается не попасть в лог?
Если баг не в midlevel коде (точнее, не только там, поскольку
хотя бы один там есть - собственно неработа обработчика ошибок) - что
такого изуродовали в aha1542.c, что он начал выделывать подобные кренделя?
> Alex
--- ifmail v.2.14.os-p2 * Origin: долой %@ство! (2:5020/28.101@fidonet)
