Re: LILO and serial speeds over 9600

James Sutherland
2001-02-13T14:00:25Z

On Tue, 13 Feb 2001, Russell King wrote:

> James Sutherland writes:
> > If the kernel starts spewing data faster than you can send it to the far
> > end, either the data gets dropped, or you block the kernel. Having the
> > kernel hang waiting to send a printk to the far end seems like a bad
> > situation...
>
> It can actually be useful. Why? Lets take a real life example: the
> recent IDE multi-sector write bug.
>
> In that specific case, I was logging through one 115200 baud serial port
> the swapin activity (in do_swap_page), the swap out activity (in
> try_to_swap_out), as well as every IDE request down to individual buffers
> as they were written to/read from the drive. This produces a rather a
> lot of data, far faster than a 115200 baud serial port can send it.
>
> The ability then to run scripts which can interpret the data and
> pick out errors (eg, we swap in data that is different from the data
> that was swapped out) was invaluable for tracking down the problem.
>
> Had messages been dropped, this would not have been possible or would
> have indicated false errors. Blocking the kernel while debug stuff
> was sent was far more preferable to loosing messages in this case.
> I would imagine that that is also true for the majority of cases as
> well.

OK, in this particular case you need to log EVERYTHING for diagnostic
purposes. In most cases, though, I'd rather have some messages dropped
than have the machine slow to a crawl...

Would you be OK with a "blocking netconsole" option, to provide this
behavious where needed? If it's the default, I bet the next Mindcraft
tests will be run with verbose logging on a 9600bps link :-)

Most people wouldn't need/want this, but I can see it would be
useful: giving the user this choice seems a better option. Also, losses on
a 10 or 100 Mbit/sec Ethernet connection will be rather less likely than
they could on a serial link!

James.