Re: [PATCH] apci: dump slit

Ingo Molnar
2008-09-14T12:26:48Z

* 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