|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Andrey Melnikoff 2:5020/400 08 Dec 2004 15:00:23
To : Eugene B. Berdnikov
Subject : Re: Serial console
--------------------------------------------------------------------------------
Eugene B. Berdnikov <berd@desert.ihep.su> wrote:
> Andrey Melnikoff <temnota+news@kmv.ru> wrote:
> AM> Eugene B. Berdnikov <berd@desert.ihep.su> wrote:
> >> Выключить hardware flow control я как-то не додумался, сам удивляюсь,
> >> почему эта очевидная вроде мысль в голову не пришла...
> AM> Да вем, бганеька, тесетром работать надо. Вон у меня половина машин с
> AM> serialconsole собрана и ниодна не виснет. Хотя, последняя уже несколько
> AM> месяцев стоит без подключенного шланга.
> Мда. Мне, наверное, померещилось, что целая шеренга машин не хочет
> ребутаться, причём с удивительным упорством. :) Жаль, фермы уже нет.
> А работать тестером свежих ядер как-то не очень хочется...
Значит неправильно их готовишь :)
> >> довольно смутные, и мне почему-то казалось, что если uart может
> >> разобраться, подключен терминал или нет, то он должен и уметь отличать
> >> состояние "терминала нет" от "терминал заблокировал передачу".
> AM> uart'у похрену. подключено-неподключено. Он байт сожрал, в fifo положил.
> AM> Если неподключено - флаг overrun выставил и всё. А вот драйверу, который
> AM> его кормит - нужно знать.
> OK, принято. Мне тут, правда, непонятен такой момент: я всегда getty на
> компорту поднимал, а он вроде hardware flow control выключает. Hо при
> шатдауне система всё равно повисала. Какого чёрта, спрашивается? :)
А почему вы у меня это спрашиваете ? Спасение утопающих - дело рук самих
утопающих. Тащщи к этому небутабельному тазику монитор с клавиатурой и дави
SqsRq-T. nmi_watchdog=1 тебе в помощь.
> Могу только утверждать, что в момент повисания getty был уже убит, как и
> sshd. Может быть, getty перед выходом hardware fc обратно возвращал?
> >> Hо вообще эти грабли должны были предусмотреть авторы console.c, причём
> >> независимо от того, насколько контролируется состояние порта.
> >> Т.е. в идеале - сделать внутренний ядерный буфер типа /proc/kmsg.
> AM> В еще большем идеале - позаимствовать у freebsd её статичный kernel
> AM> message ring buffer, который при следующей загрузке выплюнуть в syslog.
> AM> Дабы было видно, чего и как упало.
> А где этот ring buffer хранится между загрузками?
неповеришь - в памяти. В одном и том-же месте.
> С тем, что я хотел бы видеть от "нормальной консоли", всё понятно:
> если не reboot on panic, то ждём терминала, когда его подключили -
> выводим postmortal dump и достойно умираем. По-моему, это было бы самое
> правильное применение консоли. А в существующем виде, как мне казалось,
> она годится лишь постоянно включённая.
Hахер такое поведение. мне что, чтоб посмотреть никому ненужный дамп - нужно
будет ездить с монитором за 60+ км?
Лучше бы его в swap писали, и потом вынимали при swapon. А то одни поделки -
serial console, network console. network dump. Тьху.
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
