RE: Output ACPI info via sysfs

RE: Output ACPI info via sysfs

[Brown, Len]

>Currently, after booting a system there is no way to tell what 
>hardware 
>is currently in the system.  The current output from sysfs only 
>indicates what knowledge the kernel has of the system (ie, is 
>limited by 
>NR_CPUS, etc.).  However, during ACPI initialization a lot of data is 
>output to the console about the precise number of CPUs, lapics, etc.

Can you give an example of a person or program that can not
access a specific piece of information that they need?

RE: Output ACPI info via sysfs

[Peter Jones]

(sorry for breaking threading, I'm not on the list and this was
forwarded to me)

> >Currently, after booting a system there is no way to tell what 
> >hardware 
> >is currently in the system.  The current output from sysfs only 
> >indicates what knowledge the kernel has of the system (ie, is 
> >limited by 
> >NR_CPUS, etc.).  However, during ACPI initialization a lot of data is 
> >output to the console about the precise number of CPUs, lapics, etc.
> 
> Can you give an example of a person or program that can not
> access a specific piece of information that they need?

Anaconda can't determine the number of CPUs or sockets actually present
(in use or not, enabled or disabled) in a system, which we need to do in
order to determine what kernel we should install.

On x86_64 in RHEL, installation uses the default kernel, which is
compiled with support for 16 CPUs.  We can't change that because
changing CONFIG_NR_CPUS changes the module ABI, and breaks modules built
by our ISVs.  But on systems with more CPUs than that, our users are ok
with us breaking that ABI to use more CPUs, as long as it does not
effect systems with 16 or fewer processors.  So we need to probe the
number of processors and install the appropriate kernel.

I've got code to read the ACPI tables from userland right now, but it
isn't terribly reliable.  Some systems lock up if you read the tables
while X is running, and some systems sometimes give erroneous data.  In
both cases, it seems the earlier you read the tables the better, and of
course the kernel reads them while it's still only got 1 CPU running,
which is the best possible case.  The kernel hasn't triggered any of the
failures we've seen, and since it already has to read the tables, this
would be the best place for userland to get that data.

-- 
  Peter

RE: Output ACPI info via sysfs

[Brown, Len]

 
>Anaconda can't determine the number of CPUs or sockets actually present
>(in use or not, enabled or disabled) in a system, which we 
>need to do in
>order to determine what kernel we should install.

do you care about logical processors only,
or do you also care if the processors are HT or multi-core
in the same package?

>On x86_64 in RHEL, installation uses the default kernel, which is
>compiled with support for 16 CPUs.  We can't change that because
>changing CONFIG_NR_CPUS changes the module ABI, and breaks 
>modules built
>by our ISVs.  But on systems with more CPUs than that, our users are ok
>with us breaking that ABI to use more CPUs, as long as it does not
>effect systems with 16 or fewer processors.  So we need to probe the
>number of processors and install the appropriate kernel.
>
>I've got code to read the ACPI tables from userland right now, but it
>isn't terribly reliable.  Some systems lock up if you read the tables
>while X is running, and some systems sometimes give erroneous data.  In
>both cases, it seems the earlier you read the tables the better, and of
>course the kernel reads them while it's still only got 1 CPU running,
>which is the best possible case.  The kernel hasn't triggered 
>any of the
>failures we've seen, and since it already has to read the tables, this
>would be the best place for userland to get that data.

This makes zero sense to me.
Except for very very large systems the enumerate the processors in the
DSDT
(eg altix with > 256),
the processors are enumerated in the MADT, which is completely static.
In no way should dumping
it and parsing it in user-space have any effect on the integrity
of the system.

in pmtools, acpidump does this, and the madt utility below --
a rip-off of the kernel parsing code -- looks at it:

http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/

There is no reason you couldn't combine them into a single
utility to answer the question that you are asking.
It requires 0 kernel support, and doesn't even require
running in ACPI mode.

-Len

RE: Output ACPI info via sysfs

[Peter Jones]

On Sat, 2006-05-13 at 00:17 -0400, Brown, Len wrote: 
>  >Anaconda can't determine the number of CPUs or sockets actually present
> >(in use or not, enabled or disabled) in a system, which we 
> >need to do in
> >order to determine what kernel we should install.
> 
> do you care about logical processors only,
> or do you also care if the processors are HT or multi-core
> in the same package?

For this case, I only really care about logical processors.  It'd be
*nice* if the full topology were available, but it's not required here.

> 
> >On x86_64 in RHEL, installation uses the default kernel, which is
> >compiled with support for 16 CPUs.  We can't change that because
> >changing CONFIG_NR_CPUS changes the module ABI, and breaks 
> >modules built
> >by our ISVs.  But on systems with more CPUs than that, our users are ok
> >with us breaking that ABI to use more CPUs, as long as it does not
> >effect systems with 16 or fewer processors.  So we need to probe the
> >number of processors and install the appropriate kernel.
> >
> >I've got code to read the ACPI tables from userland right now, but it
> >isn't terribly reliable.  Some systems lock up if you read the tables
> >while X is running, and some systems sometimes give erroneous data.  In
> >both cases, it seems the earlier you read the tables the better, and of
> >course the kernel reads them while it's still only got 1 CPU running,
> >which is the best possible case.  The kernel hasn't triggered 
> >any of the
> >failures we've seen, and since it already has to read the tables, this
> >would be the best place for userland to get that data.
> 
> This makes zero sense to me.
> Except for very very large systems the enumerate the processors in the
> DSDT
> (eg altix with > 256),
> the processors are enumerated in the MADT, which is completely static.

Yeah, that's what I'd expect as well.

> In no way should dumping
> it and parsing it in user-space have any effect on the integrity
> of the system.

So I've seen it produce less than positive results on machines from 3
vendors.  2 of the vendors are shipping one particular (rather old)
video card, which seems to be a supporting condition of the failure.  On
these machines, reading the ACPI tables while running X on the currently
active virtual terminal causes a hard lockup.  Both of those vendors are
shipping exactly the same video card, but I've seen machines with that
card that didn't fail as well.

The other vendor's hardware _sometimes_ has bad data in the XSDT if
you've got more than 1G of ram, and I've now got workarounds in my
parser for it -- but the kernel doesn't have those, and it works just
fine.  Dunno why this is happening, but the BIOS guys at that vendor are
looking into it.  Just FWIW, acpidump has the same failure as the code
I've got (both were hacked up from the kernel code) -- on my 4G box it
tries to read 4026571728 bytes at 0x2b858abbd0 , which is clearly bogus.
But when the kernel is parsing the tables, it's getting the right data.
I really have no idea what's happening on that hardware.  I suspect a
bus analyzer is needed to tell for sure what's going on.

> in pmtools, acpidump does this, and the madt utility below --
> a rip-off of the kernel parsing code -- looks at it:
> 
> http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
> 
> There is no reason you couldn't combine them into a single
> utility to answer the question that you are asking.
> It requires 0 kernel support, and doesn't even require
> running in ACPI mode.

Yeah, this is basically what I did (but before I knew you'd written this
utility).  I still don't think it's the best idea -- poking around
in /dev/mem is ugly and bug-prone.  Doing this probe in userland means
we've got two sets of code to parse the same thing, which pretty much
always leads to bug fixes that fail to be applied to both sets of code.
So that means I've essentially got to track changes to what the kernel
parsing code (or some library-ized version of pmtools) in order to get
bug fixes.  This is a maintenance nightmare!

-- 
  Peter

RE: Output ACPI info via sysfs

[Moore, Robert]

> Doing this probe in userland means
> we've got two sets of code to parse the same thing, which pretty much
> always leads to bug fixes that fail to be applied to both sets of
code.
> So that means I've essentially got to track changes to what the kernel
> parsing code (or some library-ized version of pmtools) in order to get
> bug fixes.  This is a maintenance nightmare!

If nothing else, this is why even user code that pokes around with the
ACPI tables should be using the ACPICA code, which works anywhere.



> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Peter Jones
> Sent: Monday, May 15, 2006 11:38 AM
> To: Brown, Len
> Cc: linux-acpi@vger.kernel.org; Prarit Bhargava
> Subject: RE: Output ACPI info via sysfs
> 
> On Sat, 2006-05-13 at 00:17 -0400, Brown, Len wrote:
> >  >Anaconda can't determine the number of CPUs or sockets actually
> present
> > >(in use or not, enabled or disabled) in a system, which we
> > >need to do in
> > >order to determine what kernel we should install.
> >
> > do you care about logical processors only,
> > or do you also care if the processors are HT or multi-core
> > in the same package?
> 
> For this case, I only really care about logical processors.  It'd be
> *nice* if the full topology were available, but it's not required
here.
> 
> >
> > >On x86_64 in RHEL, installation uses the default kernel, which is
> > >compiled with support for 16 CPUs.  We can't change that because
> > >changing CONFIG_NR_CPUS changes the module ABI, and breaks
> > >modules built
> > >by our ISVs.  But on systems with more CPUs than that, our users
are ok
> > >with us breaking that ABI to use more CPUs, as long as it does not
> > >effect systems with 16 or fewer processors.  So we need to probe
the
> > >number of processors and install the appropriate kernel.
> > >
> > >I've got code to read the ACPI tables from userland right now, but
it
> > >isn't terribly reliable.  Some systems lock up if you read the
tables
> > >while X is running, and some systems sometimes give erroneous data.
In
> > >both cases, it seems the earlier you read the tables the better,
and of
> > >course the kernel reads them while it's still only got 1 CPU
running,
> > >which is the best possible case.  The kernel hasn't triggered
> > >any of the
> > >failures we've seen, and since it already has to read the tables,
this
> > >would be the best place for userland to get that data.
> >
> > This makes zero sense to me.
> > Except for very very large systems the enumerate the processors in
the
> > DSDT
> > (eg altix with > 256),
> > the processors are enumerated in the MADT, which is completely
static.
> 
> Yeah, that's what I'd expect as well.
> 
> > In no way should dumping
> > it and parsing it in user-space have any effect on the integrity
> > of the system.
> 
> So I've seen it produce less than positive results on machines from 3
> vendors.  2 of the vendors are shipping one particular (rather old)
> video card, which seems to be a supporting condition of the failure.
On
> these machines, reading the ACPI tables while running X on the
currently
> active virtual terminal causes a hard lockup.  Both of those vendors
are
> shipping exactly the same video card, but I've seen machines with that
> card that didn't fail as well.
> 
> The other vendor's hardware _sometimes_ has bad data in the XSDT if
> you've got more than 1G of ram, and I've now got workarounds in my
> parser for it -- but the kernel doesn't have those, and it works just
> fine.  Dunno why this is happening, but the BIOS guys at that vendor
are
> looking into it.  Just FWIW, acpidump has the same failure as the code
> I've got (both were hacked up from the kernel code) -- on my 4G box it
> tries to read 4026571728 bytes at 0x2b858abbd0 , which is clearly
bogus.
> But when the kernel is parsing the tables, it's getting the right
data.
> I really have no idea what's happening on that hardware.  I suspect a
> bus analyzer is needed to tell for sure what's going on.
> 
> > in pmtools, acpidump does this, and the madt utility below --
> > a rip-off of the kernel parsing code -- looks at it:
> >
> > http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
> >
> > There is no reason you couldn't combine them into a single
> > utility to answer the question that you are asking.
> > It requires 0 kernel support, and doesn't even require
> > running in ACPI mode.
> 
> Yeah, this is basically what I did (but before I knew you'd written
this
> utility).  I still don't think it's the best idea -- poking around
> in /dev/mem is ugly and bug-prone.  Doing this probe in userland means
> we've got two sets of code to parse the same thing, which pretty much
> always leads to bug fixes that fail to be applied to both sets of
code.
> So that means I've essentially got to track changes to what the kernel
> parsing code (or some library-ized version of pmtools) in order to get
> bug fixes.  This is a maintenance nightmare!
> 
> --
>   Peter
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Output ACPI info via sysfs

[Brown, Len]

I see.
the /dev/mem reader tickles some hardware wrong in some cases.

>The other vendor's hardware _sometimes_ has bad data in the XSDT if
>you've got more than 1G of ram, and I've now got workarounds in my
>parser for it -- but the kernel doesn't have those, and it works just
>fine.  Dunno why this is happening, but the BIOS guys at that 
>vendor are looking into it.  Just FWIW, acpidump has the same
>failure as the code I've got (both were hacked up from the kernel code)
> -- on my 4G box it tries to read 4026571728 bytes at 0x2b858abbd0 ,
which is 
>clearly bogus.

sure looks like a wrap-around or a sign bug, being so close to 4GB.

Is this still true for acpidump in the latest pmtools here?:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/

Bob,
the latest, 20051111, is indeed based on the ACPICA headers.

>But when the kernel is parsing the tables, it's getting the right data.
>I really have no idea what's happening on that hardware.  I suspect a
>bus analyzer is needed to tell for sure what's going on.

I can't explain why the kernel works and the latest acpidump doesn't,
but I'm willing to help fix the latest acpidump so it does.

>...
>I still don't think it's the best idea -- poking around
>in /dev/mem is ugly and bug-prone.  Doing this probe in userland means
>we've got two sets of code to parse the same thing, which pretty much
>always leads to bug fixes that fail to be applied to both sets of code.
>So that means I've essentially got to track changes to what the kernel
>parsing code (or some library-ized version of pmtools) in order to get
>bug fixes.  This is a maintenance nightmare!

On the grand scale of nigthmares, this is not a big one.
This code nearly never changes.  Also, the user-land utility
can work even when the kernel is broken.

I don't really see a case to bloat the kernel here.
Perhaps all the user-space parser needs it a reliable
physical address for the MADT?

-Len

RE: Output ACPI info via sysfs

[Peter Jones]

On Mon, 2006-05-15 at 18:21 -0400, Brown, Len wrote:
> I see.
> the /dev/mem reader tickles some hardware wrong in some cases.

Yes.

> sure looks like a wrap-around or a sign bug, being so close to 4GB.

It's just bad data in the table, AFAICS.

> Is this still true for acpidump in the latest pmtools here?:
> http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
> 
> Bob,
> the latest, 20051111, is indeed based on the ACPICA headers.

Yeah, still true there.  I've got a workaround in my code.  Here's a
patch against pmtools that makes it work on this box:

--- pmtools-20051111/madt/tables.c.orig	2006-05-16 05:57:03.000000000 -0400
+++ pmtools-20051111/madt/tables.c	2006-05-16 05:57:04.000000000 -0400
@@ -514,6 +514,8 @@
 	acpi_table_print(header, sdt_pa);
 
 	for (i = 0; i < sdt_count; i++) {
+		if (sdt_entry[i].pa == 0 && sdt_entry[i].id == ACPI_TABLE_UNKNOWN)
+			continue;
 
 		/* map in just the header */
 		header = (struct acpi_table_header *)
--- pmtools-20051111/acpidump/acpidump.c.orig	2006-05-16 05:26:43.000000000 -0400
+++ pmtools-20051111/acpidump/acpidump.c	2006-05-16 05:58:02.000000000 -0400
@@ -99,9 +99,18 @@
 
 static struct acpi_table_header *acpi_map_table(unsigned long where, char *sig)
 {
-	struct acpi_table_header *tbl = (struct acpi_table_header *)
+	struct acpi_table_header *tbl;
+
+	if (!where)
+	    return 0;
+	tbl = (struct acpi_table_header *)
 	    acpi_map_memory(where, sizeof(struct acpi_table_header));
-	if (!tbl || (sig && memcmp(sig, tbl->signature, 4))) return 0;
+	if (!tbl)
+	    return 0;
+	if (sig && memcmp(sig, tbl->signature, 4)) {
+	    acpi_unmap_memory((u8 *)tbl, sizeof(struct acpi_table_header));
+	    return 0;
+	}
 	unsigned size = tbl->length;
 	acpi_unmap_memory((u8 *) tbl, sizeof(struct acpi_table_header));
 	return (struct acpi_table_header *)acpi_map_memory(where, size);


Obviously this isn't a real solution, just a workaround.

> >But when the kernel is parsing the tables, it's getting the right data.
> >I really have no idea what's happening on that hardware.  I suspect a
> >bus analyzer is needed to tell for sure what's going on.
> 
> I can't explain why the kernel works and the latest acpidump doesn't,
> but I'm willing to help fix the latest acpidump so it does.

With the patch above it works on the machine with bogus data.  Still
doesn't help the machines that wedge solid :/ .

> >...
> >I still don't think it's the best idea -- poking around
> >in /dev/mem is ugly and bug-prone.  Doing this probe in userland means
> >we've got two sets of code to parse the same thing, which pretty much
> >always leads to bug fixes that fail to be applied to both sets of code.
> >So that means I've essentially got to track changes to what the kernel
> >parsing code (or some library-ized version of pmtools) in order to get
> >bug fixes.  This is a maintenance nightmare!
> 
> On the grand scale of nigthmares, this is not a big one.
> This code nearly never changes.  Also, the user-land utility
> can work even when the kernel is broken.

The problem is that the opposite is also true -- the kernel works
sometimes when userland doesn't.

> I don't really see a case to bloat the kernel here.
> Perhaps all the user-space parser needs it a reliable
> physical address for the MADT?

If you're really set on the parser to be in userland, but you're willing
to have the kernel go so far as to expose an address, why not just
expose the whole MADT as a sysfs or proc file?  (Ignoring that it'll
make gregkh scream at us...)

-- 
  Peter