From: Russell King <rmk@arm.linux.org.uk>
To: jas88@cam.ac.uk (James Sutherland)
Cc: alan@lxorguk.ukuu.org.uk (Alan Cox),
hpa@transmeta.com (H. Peter Anvin),
timw@splhi.com, Werner.Almesberger@epfl.ch (Werner Almesberger),
linux-kernel@vger.kernel.org
Subject: Re: LILO and serial speeds over 9600
Date: Tue, 13 Feb 2001 12:55:06 +0000 (GMT) [thread overview]
Message-ID: <200102131255.f1DCt6p02149@flint.arm.linux.org.uk> (raw)
In-Reply-To: <Pine.SOL.4.21.0102131056180.15957-100000@yellow.csi.cam.ac.uk> from "James Sutherland" at Feb 13, 2001 10:57:17 AM
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
next prev parent reply other threads:[~2001-02-13 13:49 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-12 15:45 Ivan Passos
2001-02-12 16:53 ` Ivan Passos
2001-02-12 18:47 ` H. Peter Anvin
2001-02-12 20:39 ` James Sutherland
2001-02-12 20:54 ` H. Peter Anvin
2001-02-12 22:55 ` James Sutherland
2001-02-14 11:45 ` Pavel Machek
2001-02-12 21:52 ` Alan Cox
2001-02-12 22:10 ` H. Peter Anvin
2001-02-12 22:25 ` Alan Cox
2001-02-12 23:11 ` Werner Almesberger
2001-02-12 23:16 ` Alan Cox
2001-02-12 23:20 ` H. Peter Anvin
2001-02-12 23:27 ` Alan Cox
2001-02-12 23:53 ` H. Peter Anvin
2001-02-13 0:11 ` Alan Cox
2001-02-13 0:17 ` Tim Wright
2001-02-13 0:23 ` H. Peter Anvin
2001-02-13 10:51 ` Alan Cox
2001-02-13 10:57 ` James Sutherland
2001-02-13 12:55 ` Russell King [this message]
2001-02-13 13:56 ` James Sutherland
2001-02-13 0:25 ` H. Peter Anvin
2001-02-12 23:35 ` James Sutherland
2001-02-12 23:51 ` H. Peter Anvin
2001-02-13 0:24 ` James Sutherland
2001-02-13 0:27 ` H. Peter Anvin
2001-02-12 23:19 ` H. Peter Anvin
2001-02-12 23:23 ` Alan Cox
2001-02-14 11:53 ` Pavel Machek
2001-02-17 17:26 ` Patrick Michael Kane
2001-02-17 17:40 ` James Sutherland
2001-02-21 3:11 ` Network console project (was: LILO and serial speeds over 9600) H. Peter Anvin
2001-02-21 9:29 ` Network console project Jan-Benedict Glaw
2001-02-22 21:52 ` Network console project (was: LILO and serial speeds over 9600) Pavel Machek
2001-02-23 15:54 ` Andreas Dilger
2001-02-12 22:46 ` LILO and serial speeds over 9600 James Sutherland
2001-02-12 22:50 ` Alan Cox
2001-02-12 18:51 ` H. Peter Anvin
2001-02-12 19:49 ` Scott Laird
2001-02-12 23:17 ` Ivan Passos
2001-02-12 23:30 ` Chris Wedgwood
2001-02-12 23:39 ` David Weinehall
2001-02-13 2:52 ` Michael Rothwell
[not found] <Pine.LNX.4.21.0102131506230.30955-100000@lefty.dyndns.org>
2001-02-13 6:12 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200102131255.f1DCt6p02149@flint.arm.linux.org.uk \
--to=rmk@arm.linux.org.uk \
--cc=Werner.Almesberger@epfl.ch \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=hpa@transmeta.com \
--cc=jas88@cam.ac.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=timw@splhi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®