On 02/11/2015 05:51 PM, Paul Menzel wrote:
Dear Timothy,
Am Mittwoch, den 11.02.2015, 11:41 -0600 schrieb Timothy Pearson:
I have recently updated the coreboot ACPI
autogeneration code to
generate valid processor _PSS objects when more than 10 cores are
installed in one system.
Unfortunately this required a rather large update to multiple boards in
order to change the _PSS object name from CPUn to CPnn. We would like
some feedback to make sure this update didn't break anything before
committing.
The patch is available at:
http://review.coreboot.org/8422
I tried to test this with an image built for QEMU/KVM as you can specify
the number of CPUs there with the switch `-smp cpus=n`. But I have not
looked yet, if the changed code is even used by the QEMU image and I did
not have time yet, to get an OS image to actually verify that everything
works.
Do you have a suggestion? Just `/proc/cpuinfo`? Does that depend on
correct ACPI entries?
Thanks,
Paul
Sorry, I should have mentioned a test procedure with my request. :-)
Boot Linux and execute:
dmesg | grep ACPI
Look for any failures in that output; they will be very obvious (e.g.
AE_NOT_FOUND, etc.).
If the dmesg output looks good and your CPU supports frequency scaling
you can also check this:
ls /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq | wc -l
If all the processor objects were created correctly the output of that
command should match the number of physical CPU cores active on your system.
Note that if your mainboard does not support ACPI processor objects
these checks won't work, but at the same time it should not have been
affected by the patch in question.
--
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645
http://www.raptorengineeringinc.com