[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-i386/38634: x86 kernels no longer produces information about cpus
The following reply was made to PR port-i386/38634; it has been noted by GNATS.
From: Andrew Doran <ad%netbsd.org@localhost>
Subject: Re: port-i386/38634: x86 kernels no longer produces information about
Date: Mon, 12 May 2008 13:39:51 +0100
On Mon, May 12, 2008 at 11:20:01AM +0000, chris%NetBSD.org@localhost wrote:
> dmesg used to contain information about cache sizes and feature flags for
> cpus (even if it was wrong for non-cpu0s).
> This information has been completely stripped and appears to have moved to
> This will cause issues should cpuctl and the kernel have different code. As
> a bug in the kernel code may not be present in cpuctl and a cache or tlb
> maybe detected incorrectly.
Please excuse me for being forthright, but I get the sense that this is a
sentimental reaction to change. The majority of the information gathered and
printed by the kernel was of no use at runtime and was only for eye candy
Items like the TLB and L1 cache information are never used. The list of
feature flags reported was incomplete and even at that, it was already a
large amount of information to casually sift through.
The CPU names were well out of date and in any case, only described what was
printed on the box that the CPU came in: it's marketing text and says
nothing about the architecture. Have a P-III Xeon? It could be a rebranded
P-II with more cache bolted on, or if you are lucky it's actually based on a
P-III core. The list goes on. Only the ID will tell you for sure what it is,
and that's why we still print it.
> To confirm the CPU caches and other information now requires you can get to
> userland, which may not be possible on all systems (eg a test boot on a new
> processor, or other installation issues)
That information is of little use when it comes to diagnosing boot failures.
It's certainly interesting for reasons of verification and benchmarking. I
agree that there is a need to print it, but it's not a job for the kernel.
> It also doesn't allow verification of changes to the kernel's detection of
> the CPU features without adding the printf's back in.
Well, I found and fixed quite a few bugs when overhauling it and that was
through tedious reading of the code and verification of changes. The
printout didn't help me with that.
Main Index |
Thread Index |