[tlug] Dmesg and CPU Information

[Curt Sampson <cjs@example.com>]

On Mon, 7 May 2007, Stephen J. Turnbull wrote:

> I thought that was what dmesg was for, logging all the low-level
> bitflicking in case inquiring minds want to know.  (That's a question,
> really.  I'm not a kernel hacker.)

Not really; logging *all* of that stuff quickly becomes quite
overwhelming. It's mostly there so you can see in general what devices
the system is probing and configuring (and not configuring), and get
leads for further debugging.

I use it mostly to figure out exactly what hardware is in the machine,
what source code files I have to look at to figure out what the kernel
is doing in some particular area, and what further debug messages to
turn on in a debugging kernel. (Speaking here as a rather casual "kernel
hacker.")

> I suppose in theory it could be better organized, but it would be
> organizationally hard since Linux kernel architecture and development
> organization is so decentralized compared to BSD.  So all of the
> different messages are being output according to the tastes of the
> developer doing that particular modules.  ("Have you ever tried to
> herd cats?" :-)

If they can agree on Kernel API changes, I'm sure they could agree on
what kind of messages things print. Anyway, Linux kernel development, in
and of itself, seems reasonably centralized, even if there are eighteen
zillion different userlands.

> > doesn't even bother to give you things such as the CPU ID string.
>
> cat /proc/cpuinfo give you what you're looking for?

Nope. As an example, here's the /proc/cpuinfo, which is a bit light on
information:

    processor       : 0
    vendor_id       : CentaurHauls
    cpu family      : 6
    model           : 7
    model name      : VIA Ezra
    stepping        : 10
    cpu MHz         : 800.065
    cache size      : 64 KB
    fdiv_bug        : no
    hlt_bug         : no
    f00f_bug        : no
    coma_bug        : no
    fpu             : yes
    fpu_exception   : yes
    cpuid level     : 1
    wp              : yes
    flags           : fpu de tsc msr cx8 mtrr pge mmx 3dnow up
    bogomips        : 1602.08
    clflush size    : 32

and the CPU-related dmesg output (I've elided quite a number of
interleaved messages which are not CPU-related), which has a bunch
of stuff that wouldn't be very interesting unless you were actively
debugging that section of the kernel:

    [   66.571992] Initializing CPU#0
    ...
    [   66.691752] Checking if this processor honours the WP bit even in supervisor mode... Ok.
    [   66.772025] Calibrating delay using timer specific routine.. 1602.08 BogoMIPS (lpj=3204179)
    ...
    [   66.772997] CPU: After generic identify, caps: 00803035 80803035 00000000 00000000 00000000 00000000 00000000
    [   66.773035] CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
    [   66.773050] CPU: L2 Cache: 64K (32 bytes/line)
    [   66.773060] CPU: After all inits, caps: 00803135 80803035 00000000 00000000 00000000 00000000 00000000
    [   66.773119] Compat vDSO mapped to ffffe000.
    [   66.773146] Remapping vsyscall page to ffffe000
    [   66.773175] Checking 'hlt' instruction... OK.
    [   66.788134] SMP alternatives: switching to UP code
    [   66.789150] Freeing SMP alternatives: 11k freed
    ...
    [   68.564152] CPU0: Centaur VIA Ezra stepping 0a
    [   68.564172] SMP motherboard not detected.
    ...
    [   68.564346] Brought up 1 CPUs

And the nice, clean, colocated, informative NetBSD output:

    cpu0 at mainbus0: (uniprocessor)
    cpu0: VIA C3 Samuel 2/Ezra (686-class), 800.07 MHz, id 0x67a
    cpu0: features 80803035<FPU,DEFAULT,TSC,MSR,MTRR>
    cpu0: features 80803035<PGE,MMX>
    cpu0: features 80803035<3DNOW>
    cpu0: "VIA Ezra"
    cpu0: I-cache 64 KB 32B/line 4-way, D-cache 64 KB 32B/line 4-way
    cpu0: L2 cache 64 KB 32B/line 4-way
    cpu0: ITLB 128 4 KB entries 8-way
    cpu0: DTLB 128 4 KB entries 8-way
    cpu0: 4 page colors

You'll note in particular that NetBSD is giving you more information
(in a more compact format) useful to build a mental model of how the
architecture is going to affect performance (Linux leaves out the cache
associativity and the translation lookaside buffer information), as well
as a much more readable CPU capability printout (very useful if you're
wondering, for example, what kind of virtualization your CPU supports).

Of course, most people nice as all this is, I'm sure that some folks
would prefer things such as broader ACPI support to easier kernel
debugging. (Though I have yet to see hibernate work properly even on a
Linux system.)

cjs
--
Curt Sampson       <cjs@example.com>        +81 90 7737 2974

Mobile sites and software consulting: http://www.starling-software.com