Messages in this thread | | | Date | Sun, 14 Sep 2008 14:26:18 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] apci: dump slit |
| |
* Pavel Machek <pavel@suse.cz> wrote:
> On Fri 2008-09-12 23:19:21, Thomas Gleixner wrote: > > On Fri, 12 Sep 2008, Andi Kleen wrote: > > > "Yinghai Lu" <yhlu.kernel@gmail.com> writes: > > > > > > > > to see how wrong could be set by BIOS. > > > > > > Just dump it from user space then. There are plenty of tools > > > to access ACPI tables. > > > > 1.) what guarantees that we reach user space ? > > We can dump in *any* kernel. > > > 2) If it is _valuable_ information which we can gather via kernel > > output, then it is much more conveniant than asking the user to type > > whatevercryptictoolcommandline and provide the output. > > Ooh, 'lets dump more junk at everyone, typing commands is hard' :-(.
no, the principle is, information like the boot-time CPUID information (and even the BIOS environment) can be indicative of _kernel bugs_. It is often essential to dump what the booting (and failing) kernel thinks is its environment.
Often that environment is corrupted (by the kernel) and that leads to problems. This 'environment' can also be affected by things like hard boot vs cold boot differences, whether it's in a kexec environment, whether it's booted as a virtual guest, etc., etc.
For a long time we had the kernel's x86 bootup pretty much as a mostly silent black box and when it broke we tried to figure things out afterwards which was difficult and error-prone. Now we've got various quite effective debug mechanisms (which includes printouts as well) and figuring out x86 problems is visibly easier. We definitely wont go back to the 'black box code, can only be debugged by a few experts' method.
So extending on that is a good and obvious idea in general - and i agree with Peter that this should be command-line dependent, i.e. not printed by default. Only printing it when 'debug' is specified on the command line is a good solution.
Ingo
| |