Как успеть обработать сообщение от ttyS1?

man 2 poll ?

Два потока - один всегда висит в ожидании чтения и пишет в буфер, второй разбирает прочитанное и сам пишет.

http://www.opennet.ru/docs/RUS/serial_guide/#advanced

не man select_tut ;)

Проблема в том, что иногда программа не успевает встать на приём, и сообщение с отчётом приходит раньше.

аппаратный FIFO включите у порта, без него вы ничего не сделаете програмно и poll/select тут не помогут - Linux не RT система. какой это процессор ?

SCHED_FIFO + rt prio

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

А read-write пользователя общаются с буфером драйвера, у него буфер на сотни байт.

из драйвера последовательного порта, считывается байт в буфер

Читайте внимательно

Проблема в том, что иногда программа не успевает встать на приём, и сообщение с отчётом приходит раньше. Получается, что программа блокируется на функции read().

read() читает буфер.

Пускай ТС читает внимательно, мне оно по барабану - у меня работает.

пеши под dos и не выгребывайся. Лялих не нужен.

ARM9 проц. возможности включить аппаратный FIFO нету

а то, что у меня ядро 2.4 дело не меняет? там, как я помню, старый планировщик

По поводу аппаратного FIFO - дело не в процессоре, он включается на контроллере RS232 драйвером, и обычно это делается по умолчанию. Попробуй посмотреть setserial.
Хотя это на самом деле радикально не поможет.
Что бы обеспечить дополнительную буферизацию, можно попробовать работать не непосредственно с ttyS1, а через посредника типа socat или coproc в bash.
Но если программа сама пытается выдавать какие-либо ioctl на устройство, например, устанавливать режим, то ничего, скорее всего, не выйдет.

а то, что у меня ядро 2.4 дело не меняет? там, как я помню, старый планировщик

Может и меняет. Лучше спросите у тех, кто успел 2.4 поразрабатывать