On Wed, 10 Jun 2009, Nicolas Williams wrote:
> On Wed, Jun 10, 2009 at 04:15:30PM -0700, Randy Fishel wrote:
> > This morning I had the thought that maybe some or all of this
> > functionality could be handled by having a 'logger' provider in
> > dtrace. My needs are to have a lightweight non-volatile logging
> > mechansim that will continue to function while normal hardware I/O
> > channels are being stopped or powered off. But I considered that this
> > "feature" might be usefull to other consumers.
>
> Have you looked at anonymous DTrace scripts? Those are used for tracing
> early in boot, and their results end up in a kernel-land buffer until
> retrieved from user-land once the system is up. You could use the same
> approach. One of the nice things about this is that if there's a panic
> you can always get at the buffered data using kmdb (if you can't use
> kmdb but can force a dump then you can always look at the data in the
> dump).
>
> Nico
> --
>
Anonymous DTrace is useful for early in the kernel startup, but what
we have for suspend and resume is actually a running instance that is
frozen. And in the midst of the freeze, the instance can be
completely tossed and there is no core dump. A common example, is
that we stop all hardware (turn off the monitor, and spin down disks),
and then nothing. Power doesn't go off and it looks like a hang. The
only resort is to power-cycle, so there will be no core file, nor will
there be any buffers for dtrace or kmdb to look at (same for resume,
but that has the added burden of making sure the "logging" device
gets restored to a usable state).
The debug prototype continues to log messages to the serial port, so
at least there is some idea as to what it was last doing (granted, if
the machine goes off to the BIOS, all hope really is lost). But this
is only useful in debug kernels, and there are many failures in the
field that I haven't a clue how to solve, as I don't know where it
gets lost.
So even though some form of anonymous tracing will be used (it will
need to be all in the kernel, as the first thing we stop is userland),
without a non-volatile logging mechanism, it is a core that goes into
the ether.
Where I eventually landed, is that I need to have (or implement) a
mechanism to send dtrace information to an arbitrarily defined
streaming device. I was considering it as part of a 'power
management' provider, but it seemed this might be useful outside of a
pm provider.
Cheers!
---- Randy
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
