On Fri, 26 Mar 2010 11:26:01 -0700 patrick keshishian
<pkesh...@gmail.com> wrote:
> On Fri, Mar 26, 2010 at 3:36 AM, Nick Holland
> <n...@holland-consulting.net> wrote:
> > Andreas Gerdd wrote:
> >> Hello.
> >>
> >> I've an Intel E6300 Dual Core 2.8 system.
> >>
> >> Whenever I try to see such a dmesg output, I get the following:
> >>
> >> # dmesg -N /bsd.sp
> >> dmesg: pread: Bad address
> >> dmesg: kvm_read: invalid address (0) (0)
> >>
> >> However, typing just "dmesg" works fine, shows the output for
> >> GENERIC.MP, but i try to see a dmesg output for the GENERIC kernel
> >> as well, so i can send them both to dm...@openbsd.org
> >
> > dmesg is a property of a running kernel, not of a kernel sitting on
> > the disk. If you are running snapshot or release kernels, we know
> > what is in your kernel file, we want to see how it works with your
> > hardware (of course, we also want to see the first few lines which
> > show us what version you are running).
> >
> > So, to get a dmesg from GENERIC.MP, you run bsd.mp, for GENERIC, you
> > run bsd. You can't pull a dmesg out of a kernel that wasn't run
> > [...]
>
> If I'm reading this correctly, what you are saying is the -N option to
> dmesg can be considered to a bug?
>
Nope. The *values* are read from /dev/kmem, or alternatively from a
core file via the -M flag. On the other hand the *names* of those
values are typically read from /bsd, or alternatively from another
kernel file via the -N flag.
In other words, you're looking at name->value pairs, where the symbolic
names are stored in one place (a kernel file), and the values are
stored in another place (typically /dev/kmem of the running kernel, or
saved to a core file on a crash).
Think about it this way; you use the "boot> " prompt to boot up your
experimental kernel named "/bsd.exp". It dumps core before you can get
a dmesg, so you want to see what the heck was going on. You reboot with
your normal kernel "/bsd" and use dmesg on the core file, and tell it
where to find the corresponding names (i.e. in your experimental kernel)
# dmesg -M bsd.exp.core -N /bsd.exp
Obviously, the default input for values, /dev/kmem, will only give
values of the currently running kernel, hence to get those values you
either need to running a particular kernel, or crash it to dump core.
As for dmesg picking the right kernel file for getting the names of the
currently running kernel, there is either some magic in demsg which
picks the right kernel from disk, or a properly running kernel does not
need to read names from the kernel file since they're already in memory.
jcr
