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.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 15 2001 - 21:00:21 EST