Hi,
Im new to this group.
I want to get some information from BIOS. i.e i want to know whether
Hyperthreading is Enabled/Disabled(as per BIOS settings) from an user
applications program.
Please reply, if anybody has worked on it.
--
Thanks & Regards
Madhukar Mythri
Wipro Technologies
Bangalore.
Off: +91 80 30294361.
M: +91 9886442416.
Also sprach Madhukar Mythri <[email protected]> (Mon, 08 May
2006 19:44:00 +0530):
> Hi,
> Im new to this group.
> I want to get some information from BIOS. i.e i want to know whether
> Hyperthreading is Enabled/Disabled(as per BIOS settings) from an user
> applications program.
Maybe dmidecode[1] is something for you. However, I'm not sure about HT
there. It's userspace.
apt-get install dmidecode or
[1] http://www.nongnu.org/dmidecode/
sl ritch
But, HT information is not present in demicode(SMBIOS info..)
Richard Mittendorfer wrote:
>Also sprach Madhukar Mythri <[email protected]> (Mon, 08 May
>2006 19:44:00 +0530):
>
>
>>Hi,
>> Im new to this group.
>>I want to get some information from BIOS. i.e i want to know whether
>>Hyperthreading is Enabled/Disabled(as per BIOS settings) from an user
>>applications program.
>>
>>
>
>Maybe dmidecode[1] is something for you. However, I'm not sure about HT
>there. It's userspace.
>
>apt-get install dmidecode or
>[1] http://www.nongnu.org/dmidecode/
>
>sl ritch
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
--
Thanks & Regards
Madhukar Mythri
Wipro Technologies
Bangalore.
Off: +91 80 30294361.
M: +91 9886442416.
On Mon, 2006-05-08 at 19:44 +0530, Madhukar Mythri wrote:
> Hi,
> Im new to this group.
> I want to get some information from BIOS. i.e i want to know whether
> Hyperthreading is Enabled/Disabled(as per BIOS settings) from an user
> applications program.
there is no standard way to do this. You can use /proc/cpuinfo to see if
the kernel found ht'd processors. But that's the best you can do.
(well you could grovel through the acpi tables just like the kernel
does, but you really don't want to do that from userspace)
Also sprach Madhukar Mythri <[email protected]> (Mon, 08 May
2006 20:24:56 +0530):
> But, HT information is not present in demicode(SMBIOS info..)
Never had a HT system, shouldn't this info be availible through
/var/log/dmesg, /proc/couinfo or /proc/acpi/processor or something like
this?
sl ritch
Please don't top-post and CC me, I'm reading this list.
Arjan van de Ven wrote:
>On Mon, 2006-05-08 at 19:44 +0530, Madhukar Mythri wrote:
>
>
>>Hi,
>> Im new to this group.
>>I want to get some information from BIOS. i.e i want to know whether
>>Hyperthreading is Enabled/Disabled(as per BIOS settings) from an user
>>applications program.
>>
>>
>
>there is no standard way to do this. You can use /proc/cpuinfo to see if
>the kernel found ht'd processors. But that's the best you can do.
>(well you could grovel through the acpi tables just like the kernel
>does, but you really don't want to do that from userspace)
>
>
>
>
"proc/cpuinfo" says only HT support is their or not but, it will not say
whether HT is Enalbled/Disabled..
How to read ACPI tables ? Can you give little info on this...
even from Driver program, if its possible please tell me...
--
Thanks & Regards
Madhukar Mythri
Wipro Technologies
Bangalore.
Off: +91 80 30294361.
M: +91 9886442416.
Madhukar Mythri wrote:
> "proc/cpuinfo" says only HT support is their or not but, it will not
> say whether HT is Enalbled/Disabled..
> How to read ACPI tables ? Can you give little info on this...
> even from Driver program, if its possible please tell me...
Look at the 'physical id', 'siblings', 'core id', and 'cpu cores' fields
in /proc/cpuinfo. If 'siblings' exists, you are hyperthreaded and you
can detect which cpu the other thread is by matching physical id and
core id.
--
error compiling committee.c: too many arguments to function
On Mon, 2006-05-08 at 20:34 +0530, Madhukar Mythri wrote:
>
> >
> "proc/cpuinfo" says only HT support is their or not but, it will not
> say
> whether HT is Enalbled/Disabled..
no I didn't mean the cpu flags line, but the "sibblings" line. If that
says "2" then HT is enabled ;)
Hi,
On 08/05/06, Madhukar Mythri <[email protected]> wrote:
[snip]
> "proc/cpuinfo" says only HT support is their or not but, it will not say
> whether HT is Enalbled/Disabled..
> How to read ACPI tables ? Can you give little info on this...
> even from Driver program, if its possible please tell me...
>
How about comparing /sys/devices/system/cpu/cpu0/topology/core_id and
/sys/devices/system/cpu/cpu1/topology/core_id values?
On my northwood ht (single core) cpu0/topology/core_id and
cpu1/topology/core_id contain "0". For dual core system should be
something like
cpu0/topology/core_id = 0
cpu1/topology/core_id = 0
cpu2/topology/core_id = 1
cpu3/topology/core_id = 1
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
On Mon, 8 May 2006, Madhukar Mythri wrote:
> Hi,
> Im new to this group.
> I want to get some information from BIOS. i.e i want to know whether
> Hyperthreading is Enabled/Disabled(as per BIOS settings) from an user
> applications program.
>
> Please reply, if anybody has worked on it.
>
The BIOS settings, and where the BIOS information is stored, is
different for each and every BIOS. That's why there is a BIOS
setup screen. You can't run this screen from within the 32-bit
protected-mode environment of Linux. You could, however, implement
a VM-86 environment, just as is done for dosemu, the MS-DOS
emulator. However, dosemu creates a virtual BIOS environment and
doesn't use the real one, therefore you would have to copy over
a the real BIOS pages in order to run the BIOS setup screen.
The bottom line is that it's possible, but very difficult. That's
why relevant information is gathered by Linux and put into
the /proc file-system. If you have hyper-threading, it should
show up as two or more CPUs in /proc/cpuinfo.
> --
> Thanks & Regards
> Madhukar Mythri
> Wipro Technologies
> Bangalore.
> Off: +91 80 30294361.
> M: +91 9886442416.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips).
New book: http://www.lymanschool.com
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
Arjan van de Ven wrote:
>On Mon, 2006-05-08 at 20:34 +0530, Madhukar Mythri wrote:
>
>
>>"proc/cpuinfo" says only HT support is their or not but, it will not
>>say
>>whether HT is Enalbled/Disabled..
>>
>>
>
>no I didn't mean the cpu flags line, but the "sibblings" line. If that
>says "2" then HT is enabled ;)
>
>
>
>
>
I forgot mention, that my Kernel is NONSMP based kernel....
--
Thanks & Regards
Madhukar Mythri
Wipro Technologies
Bangalore.
Off: +91 80 30294361.
M: +91 9886442416.
On Mon, May 08, 2006 at 08:58:51PM +0530, Madhukar Mythri wrote:
> I forgot mention, that my Kernel is NONSMP based kernel....
Then your application can't use HT anyway, so why bother?
Erik
--
+-- Erik Mouw -- http://www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
On Mon, 8 May 2006, Michal Piotrowski wrote:
> Hi,
>
> On 08/05/06, Madhukar Mythri <[email protected]> wrote:
> [snip]
>> "proc/cpuinfo" says only HT support is their or not but, it will not say
>> whether HT is Enalbled/Disabled..
>> How to read ACPI tables ? Can you give little info on this...
>> even from Driver program, if its possible please tell me...
>>
>
> How about comparing /sys/devices/system/cpu/cpu0/topology/core_id and
> /sys/devices/system/cpu/cpu1/topology/core_id values?
>
> On my northwood ht (single core) cpu0/topology/core_id and
> cpu1/topology/core_id contain "0". For dual core system should be
> something like
>
> cpu0/topology/core_id = 0
> cpu1/topology/core_id = 0
> cpu2/topology/core_id = 1
> cpu3/topology/core_id = 1
>
> Regards,
> Michal
>
The problem is that if the BIOS didn't turn them on, there might
be only /proc/sys/devices/system/cpu/cpu0, nothing else... and
you get bad information as well. This machine has a dual-core
CPU that *was* a hyper-threaded, two core device until I
changed the motherboard. Now it's just a single core, non
HT device even though the HT flag is set. There isn't any
way to turn it ON and the motherboard vendor, CompUSA, claims
that there is "no such thing" as HT. FYI, the board was made
by Intel and I think they invented HT. Nevertheless, the
consumer ends up with the crap that the vendors supply and
that's that! My only recourse was to just return the board
and get my money back. I needed the board because the previous
one from Tyan didn't work at all!
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping : 7
cpu MHz : 2793.171
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
^__ HT ready
bogomips : 5592.89
Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips).
New book: http://www.lymanschool.com
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
Erik Mouw wrote:
>On Mon, May 08, 2006 at 08:58:51PM +0530, Madhukar Mythri wrote:
>
>
>>I forgot mention, that my Kernel is NONSMP based kernel....
>>
>>
>
>Then your application can't use HT anyway, so why bother?
>
>
>Erik
>
>
>
yeah, your are correct. but, the thing is my superiors want, even if
kernel not reconize/use HT, we have to capture it from BIOS...
Thats why i asked as, how to read BIOS information?
--
Thanks & Regards
Madhukar Mythri
Wipro Technologies
Bangalore.
Off: +91 80 30294361.
M: +91 9886442416.
On Tue, 2006-05-09 10:53:10 +0530, Madhukar Mythri <[email protected]> wrote:
> Erik Mouw wrote:
> > On Mon, May 08, 2006 at 08:58:51PM +0530, Madhukar Mythri wrote:
> > > I forgot mention, that my Kernel is NONSMP based kernel....
> > Then your application can't use HT anyway, so why bother?
> yeah, your are correct. but, the thing is my superiors want, even if
> kernel not reconize/use HT, we have to capture it from BIOS...
Some things just won't work. I'd like to have a nice house and not
pay for it. Won't work either:)
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
On Tue, May 09, 2006 at 10:53:10AM +0530, Madhukar Mythri wrote:
> Erik Mouw wrote:
> >On Mon, May 08, 2006 at 08:58:51PM +0530, Madhukar Mythri wrote:
> >>I forgot mention, that my Kernel is NONSMP based kernel....
> >
> >Then your application can't use HT anyway, so why bother?
>
> yeah, your are correct. but, the thing is my superiors want, even if
> kernel not reconize/use HT, we have to capture it from BIOS...
> Thats why i asked as, how to read BIOS information?
You can't. Tell your superiors life sucks.
Erik
--
+-- Erik Mouw -- http://www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
On Maw, 2006-05-09 at 10:53 +0530, Madhukar Mythri wrote:
> yeah, your are correct. but, the thing is my superiors want, even if
> kernel not reconize/use HT, we have to capture it from BIOS...
> Thats why i asked as, how to read BIOS information?
You ask the BIOS vendor for the exact board in question.
If you want to ask the processor itself then you can use the model
specific registers. These are accessible via /dev/cpu/<cpuid>/msr so you
can perform the Intel recommended sequence for checking if the processor
has HT enabled.
It might be simpler to look in /proc/cpuinfo if you just need the basic
information
Alan Cox wrote:
> On Maw, 2006-05-09 at 10:53 +0530, Madhukar Mythri wrote:
>
>> yeah, your are correct. but, the thing is my superiors want, even if
>>kernel not reconize/use HT, we have to capture it from BIOS...
>>Thats why i asked as, how to read BIOS information?
>
>
> You ask the BIOS vendor for the exact board in question.
>
> If you want to ask the processor itself then you can use the model
> specific registers. These are accessible via /dev/cpu/<cpuid>/msr so you
> can perform the Intel recommended sequence for checking if the processor
> has HT enabled.
>
> It might be simpler to look in /proc/cpuinfo if you just need the basic
> information
He's actually asking if the BIOS has turned on HT, not if some other
means has...
BUT, the only thing I can think of is turning OFF HT in the BIOS,
reading the CMOS, storing it somewhere, turning ON HT, storing
that somewhere and comparing them. Then he'll know that in his
specific BIOS revision on his specific mainboard that bit is
stored in one specific place and he can go from there.
Messy, definately not recommended, stupid but hey, if the bosses
ask for it and you gotta give it ..
Just make triple sure you tell them that if you upgrade the BIOS
the test might fail or if you change mainboard, etc.
// Stefan
Also sprach Stefan Smietanowski <[email protected]> (Tue, 09 May 2006
14:29:01 +0200):
> Alan Cox wrote:
> > On Maw, 2006-05-09 at 10:53 +0530, Madhukar Mythri wrote:
> >
> >> yeah, your are correct. but, the thing is my superiors want, even
> >if >kernel not reconize/use HT, we have to capture it from BIOS...
> >>Thats why i asked as, how to read BIOS information?
> >
> >
> > You ask the BIOS vendor for the exact board in question.
> >
> > If you want to ask the processor itself then you can use the model
> > specific registers. These are accessible via /dev/cpu/<cpuid>/msr so
> > you can perform the Intel recommended sequence for checking if the
> > processor has HT enabled.
> >
> > It might be simpler to look in /proc/cpuinfo if you just need the
> > basic information
>
> He's actually asking if the BIOS has turned on HT, not if some other
> means has...
>
> BUT, the only thing I can think of is turning OFF HT in the BIOS,
> reading the CMOS, storing it somewhere, turning ON HT, storing
> that somewhere and comparing them. Then he'll know that in his
> specific BIOS revision on his specific mainboard that bit is
> stored in one specific place and he can go from there.
>
> Messy, definately not recommended, stupid but hey, if the bosses
> ask for it and you gotta give it ..
>
> Just make triple sure you tell them that if you upgrade the BIOS
> the test might fail or if you change mainboard, etc.
IIRC the chipset should know about this?
Something like hex /sys/devices/pci0000:0/0000:00:00.0/config and
comparing registers with the chipset's datasheet?
> // Stefan
sl ritch
Thanks alot for all...
Regards,
Madhukar Mythri.
Richard Mittendorfer wrote:
>Also sprach Stefan Smietanowski <[email protected]> (Tue, 09 May 2006
>14:29:01 +0200):
>
>
>>Alan Cox wrote:
>>
>>
>>>On Maw, 2006-05-09 at 10:53 +0530, Madhukar Mythri wrote:
>>>
>>>
>>>
>>>> yeah, your are correct. but, the thing is my superiors want, even
>>>>
>>>>
>>>if >kernel not reconize/use HT, we have to capture it from BIOS...
>>>
>>>
>>>>Thats why i asked as, how to read BIOS information?
>>>>
>>>>
>>>You ask the BIOS vendor for the exact board in question.
>>>
>>>If you want to ask the processor itself then you can use the model
>>>specific registers. These are accessible via /dev/cpu/<cpuid>/msr so
>>>you can perform the Intel recommended sequence for checking if the
>>>processor has HT enabled.
>>>
>>>It might be simpler to look in /proc/cpuinfo if you just need the
>>>basic information
>>>
>>>
>>He's actually asking if the BIOS has turned on HT, not if some other
>>means has...
>>
>>BUT, the only thing I can think of is turning OFF HT in the BIOS,
>>reading the CMOS, storing it somewhere, turning ON HT, storing
>>that somewhere and comparing them. Then he'll know that in his
>>specific BIOS revision on his specific mainboard that bit is
>>stored in one specific place and he can go from there.
>>
>>Messy, definately not recommended, stupid but hey, if the bosses
>>ask for it and you gotta give it ..
>>
>>Just make triple sure you tell them that if you upgrade the BIOS
>>the test might fail or if you change mainboard, etc.
>>
>>
>
>IIRC the chipset should know about this?
>Something like hex /sys/devices/pci0000:0/0000:00:00.0/config and
>comparing registers with the chipset's datasheet?
>
>
>
>>// Stefan
>>
>>
>
>sl ritch
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
Madhukar Mythri wrote:
> Erik Mouw wrote:
>
>> On Mon, May 08, 2006 at 08:58:51PM +0530, Madhukar Mythri wrote:
>>
>>
>>> I forgot mention, that my Kernel is NONSMP based kernel....
>>>
>>
>> Then your application can't use HT anyway, so why bother?
>>
>>
>> Erik
>>
>>
>>
> yeah, your are correct. but, the thing is my superiors want, even if
> kernel not reconize/use HT, we have to capture it from BIOS...
> Thats why i asked as, how to read BIOS information?
>
>
Each motherboard/bios *VERSION* can and sometimes does change the location
of the internal bits that define what and where each bios setting is.
I know upgrading major bios version on a motherboard will often leave
the motherboard needing a full cmos clear because what the bits mean
changed and the new usage of the bits does not allow the motherboard
to post.
I don't believe that they actually document the internal settings, and
even if they did, the number of motherboard/bios combinations is way
too high for it to work easily.
This is why there (in general) are no programs that change the bios
settings from the OS, there is no general solution that works for all,
and there are too many combinations, and too little documentation.
Roger
Arjan van de Ven:
> But that's the best you can do.
> (well you could grovel through the acpi tables just like the kernel
> does, but you really don't want to do that from userspace)
Obviously that would be tricky in this case. But in general it seems
like writing an acpi table parser should be doable. Couldn't you
just search through /dev/mem like dmidecode does? What's the
difficult part?
regards,
dan carpenter
On Wed, 2006-05-10 at 01:32 -0700, Dan Carpenter wrote:
> Arjan van de Ven:
> > But that's the best you can do.
> > (well you could grovel through the acpi tables just like the kernel
> > does, but you really don't want to do that from userspace)
>
> Obviously that would be tricky in this case. But in general it seems
> like writing an acpi table parser should be doable. Couldn't you
> just search through /dev/mem like dmidecode does? What's the
> difficult part?
the difficult part is in all the exceptions, quirks and special rules
the kernel uses (like "don't trust this table if acpi is off", and the
rules for acpi to not get enabled at runtime are highly complex and
continuously evolving).