> > So far so good, but during this torture-test, vgetty failed to answer
> > the phone because it lost some characters and then it reported 'no such
> > file or directory' on a read. May this happen even though I've
> > irqtuned the modem device (/dev/ttyS2 in this case, a 16650 on irq 5)
> > to the highest priority? (well, this is no loss, as the file-system
> > would be too slow to record voice-data anyway)
>
> For this reason, I have long ago patched vgetty to run realtime
> priority. I run a modified vg_nmp playing via the sound card realtime
> too. Never had any lossage.
Ok, but it was not my aim to get vgetty fixed, as I think it's not too
broken. The point is, that i think the serial driver shouldn't loose
characters even under high load. It was the RING message from the
Modem that got mangeled and I think the driver should always be able
to receive 5 bytes if it has the highest IRQ-priority. Apart from that
high-load situation, there is another hint for the serial driver to
have small problem: vgetty reports 'select returned 0' and then resets
the modem at random times (about hourly). I haven't seen this in
2.0.29 and yesterday, I ran 2.1.54 for a couple of hours (feels quite
promising!) and it didn't happen there, either. I was not able to
match the timestamp of vgetty's log entries with any oher log entries
so I really don't know where it comes from. When I dial out, I have no
problems whatsoever, and this kernel has proven real solid over the
past days. I just mentioned that because it might serve as a hint
... hm in 2.1.54 there's the new serial driver so if only I see
strange log entries it's propably not worth bothering because there's
no real problem.
best regards,
PS thanks to everyone who contributed to this kernel!
--
Eberhard Burr finger uhl4@rzstud2.rz.uni-karlsruhe.de for PGP key
#include <stddisc.h> ------ electric cookie:
((lambda (foo) (bar foo)) (baz))