[lkml]   [1999]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: i386/RTC: old problem, new solution?
Riley Williams writes:
> Hi Richard.
> > I don't think you really need that. The kernel messages are
> > stored in time order anyway. That's generally good enough to
> > debug races.
> The problem as I see it is that syslogd's timestamps MUST sometimes
> imply races that aren't there, simply because it will timestamp an
> entire batch of messages with near enough the same time when they were
> actually spread out by several seconds, or even minutes on occasions.
> Take the messsages generated during booting: If your point is correct,
> then all messages generated prior to syslogd/klogd starting up are
> marked with effectively the same timestamp (namely the moment when
> syslogd reads them), no matter how long apart they really were, and as
> a result, any races that would've shown up with the true timestamps
> are of necessity hidden and can only be guessed at...

Bear in mind that syslogd only keeps timestamps to second resolution.
That isn't really useful for debugging races. Even microsecond
resolution can be insufficient for debugging races (these days there
are a lot of cycles per microsecond). Printing timestamps with
microsecond or better resolution would just get incredibly message.

I don't think the timestamps help much.



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.066 / U:7.520 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site