Prev: Logs and dumps for kernel panics to collect and analyze?
Next: resize a lvm volume on a raid1
From: David W. Hodgins on 7 Mar 2010 03:56
On Sat, 06 Mar 2010 23:31:35 -0500, Artist <Artist(a)sj.speakeasy.net> wrote:

>
> flags : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr
> sse sse2 ss ht nx constant_tsc pni ssse3 sse4_1

On a 32 bit system ...
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 constant_tsc up pebs bts pni dtes64 monitor ds_cpl cid xtpr

On 64 bit system ...
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 nx lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor
ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm
tpr_shadow vnmi flexpriority

The key is the lm flag. If present, it's a 64 bit processer.
If absent, it isn't.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
From: The Natural Philosopher on 7 Mar 2010 08:22
Artist wrote:
> Darren Salt wrote:
>> I demand that Artist may or may not have written...
>>
>>> On my x86_64 server with a newly installed Debian 5 I did this
>>> sequence of installation commands:
>>
>>> apt-get install gcc
>> [snip; local install of libevent-1.4.13-stable]
>>
>> That's in backports. You should get it from there instead of building it
>> yourself; see
>> http://packages.debian.org/source/lenny-backports/libevent (and
>> follow the "backports" link) for details.
>>
>> (And were it not in backports, you should install build-essential, use
>> dget
>> to fetch the .dsc of the version in testing (it'll fetch the rest of the
>> source automatically), "dpkg-source -x" the .dsc to unpack the source,
>> then
>> "debuild binary" to build it. Then dpkg (as root) to install it. Best
>> to stay
>> within the package management system wherever you reasonably can.)
>>
>>> I thought I would automatically get an installation that took full
>>> advantage of the 64 bit architecture.
>>
>> That's not determined by adding packages.
>>
>>> But looking in the directory /var/cache/apt/archives I see most of the
>>> files end in i386.deb. So now I am not sure. Is this what I should
>>> see if
>>> the full benefit if the x86_64 architecture is to be had?
>>
>> Not really. You can cross-compile for amd64 and even run the resulting
>> binaries, but your installation is i386. (However, you can at least
>> run an
>> amd64 kernel.)
>>
>> You might want to throw that away and do a full re-install, targetting
>> amd64.
>>
>> It's possible, but somewhat involved, to "migrate" it to amd64. This
>> requires
>> use of dpkg --get-selections, preserving /etc, /var/cache/debconf and
>> probably a few other bits and pieces, doing a base install, chrooting
>> into
>> it, using dpkg --set-selections, restoring all of what you preserved
>> except
>> /etc, installing the packages according to the selections (aptitude in UI
>> mode is ideal), then (selectively?) restoring /etc. You do need to
>> know your
>> way around a Debian system to some extent to be able to get away with
>> this
>> kind of installation hack, though, and I've probably omitted something
>> extremely important. Let's just say that it may, potentially, become Very
>> Interesting.
>>
>> (That said, a full install followed by copying what you've customised
>> most
>> into the new /etc will probably do. It's up to you...)
>>
>
> Thankyou for your reply. This is a big help. I will remove and reinstall
> libevent using the link that you have given.
>
> Does a similar thing need to be done for my installations of gcc, gawk,
> make, and locate?
>
> I was mistaken about x86_64. The uname -m command gives i686. But the
> gcc -v command shows the default architecture is i486:
>
> debian:/usr/share# uname -v
> #1 SMP Wed Feb 10 09:24:17 UTC 2010
> debian:/usr/share# gcc -v
> Using built-in specs.
> Target: i486-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian
> 4.3.2-1.1' --with
> -bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
> --enable-languages=c,c++,fortr
> an,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib
> --libexecdir=/u
> sr/lib --without-included-gettext --enable-threads=posix --enable-nls
> --with-gxx
> -include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
> --enable-clocale=gnu --e
> nable-libstdcxx-debug --enable-objc-gc --enable-mpfr
> --enable-targets=all --enab
> le-cld --enable-checking=release --build=i486-linux-gnu
> --host=i486-linux-gnu --
> target=i486-linux-gnu
> Thread model: posix
> gcc version 4.3.2 (Debian 4.3.2-1.1)
>
> Should the target have been i686-linux-gnu if I had the right
> configuration for it or the right gcc installed?
>
reinstall with AM64 architecture.



From: Darren Salt on 7 Mar 2010 09:25
I demand that Artist may or may not have written...

> Darren Salt wrote:
>> I demand that Artist may or may not have written...
[snip]
>>> I was mistaken about x86_64. The uname -m command gives i686.
>> Kernel. Not particularly relevant, except that that tells me that it only
>> supports native 32-bit userland.

>> /proc/cpuinfo is more interesting; particularly the first model name line
>> and flags line.

[snip]
> model name : Intel(R) Xeon(R) CPU E5405 @ 2.00GHz
[snip]
> flags : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse
> sse2 ss ht nx constant_tsc pni ssse3 sse4_1
[snip]

32-bit. However, according to Intel, that CPU is EM64T; so Debian's -amd64
kernels should be fine, as should an amd64 install.

> I have executed the command:
> apt-get remove --purge libevent
> From the documentation I understand this was supposed to remove all
> files for libevent. But the command:

All files listed as being installed from the .deb.

> locate libevent
> finds many files for libevent in the directories:
> /usr/local/src/libevent-1.4.13-stable/
> /usr/local/lib/
> Were these supposed to be removed be apt-get? Or should I remove these
> manually?

They weren't installed from a .deb, so you'll have to remove them manually.

--
| Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon
| using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army
| + http://wiki.debian.org/DebianEeePC/

Even the smallest candle burns brighter in the dark.
From: Artist on 7 Mar 2010 12:06
The Natural Philosopher wrote:
> Artist wrote:
>> Darren Salt wrote:
>>> I demand that Artist may or may not have written...
>>>
>>>> On my x86_64 server with a newly installed Debian 5 I did this
>>>> sequence of installation commands:
>>>
>>>> apt-get install gcc
>>> [snip; local install of libevent-1.4.13-stable]
>>>
>>> That's in backports. You should get it from there instead of building it
>>> yourself; see
>>> http://packages.debian.org/source/lenny-backports/libevent (and
>>> follow the "backports" link) for details.
>>>
>>> (And were it not in backports, you should install build-essential,
>>> use dget
>>> to fetch the .dsc of the version in testing (it'll fetch the rest of the
>>> source automatically), "dpkg-source -x" the .dsc to unpack the
>>> source, then
>>> "debuild binary" to build it. Then dpkg (as root) to install it. Best
>>> to stay
>>> within the package management system wherever you reasonably can.)
>>>
>>>> I thought I would automatically get an installation that took full
>>>> advantage of the 64 bit architecture.
>>>
>>> That's not determined by adding packages.
>>>
>>>> But looking in the directory /var/cache/apt/archives I see most of the
>>>> files end in i386.deb. So now I am not sure. Is this what I should
>>>> see if
>>>> the full benefit if the x86_64 architecture is to be had?
>>>
>>> Not really. You can cross-compile for amd64 and even run the resulting
>>> binaries, but your installation is i386. (However, you can at least
>>> run an
>>> amd64 kernel.)
>>>
>>> You might want to throw that away and do a full re-install,
>>> targetting amd64.
>>>
>>> It's possible, but somewhat involved, to "migrate" it to amd64. This
>>> requires
>>> use of dpkg --get-selections, preserving /etc, /var/cache/debconf and
>>> probably a few other bits and pieces, doing a base install, chrooting
>>> into
>>> it, using dpkg --set-selections, restoring all of what you preserved
>>> except
>>> /etc, installing the packages according to the selections (aptitude
>>> in UI
>>> mode is ideal), then (selectively?) restoring /etc. You do need to
>>> know your
>>> way around a Debian system to some extent to be able to get away with
>>> this
>>> kind of installation hack, though, and I've probably omitted something
>>> extremely important. Let's just say that it may, potentially, become
>>> Very
>>> Interesting.
>>>
>>> (That said, a full install followed by copying what you've customised
>>> most
>>> into the new /etc will probably do. It's up to you...)
>>>
>>
>> Thankyou for your reply. This is a big help. I will remove and
>> reinstall libevent using the link that you have given.
>>
>> Does a similar thing need to be done for my installations of gcc,
>> gawk, make, and locate?
>>
>> I was mistaken about x86_64. The uname -m command gives i686. But the
>> gcc -v command shows the default architecture is i486:
>>
>> debian:/usr/share# uname -v
>> #1 SMP Wed Feb 10 09:24:17 UTC 2010
>> debian:/usr/share# gcc -v
>> Using built-in specs.
>> Target: i486-linux-gnu
>> Configured with: ../src/configure -v --with-pkgversion='Debian
>> 4.3.2-1.1' --with
>> -bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
>> --enable-languages=c,c++,fortr
>> an,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib
>> --libexecdir=/u
>> sr/lib --without-included-gettext --enable-threads=posix --enable-nls
>> --with-gxx
>> -include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
>> --enable-clocale=gnu --e
>> nable-libstdcxx-debug --enable-objc-gc --enable-mpfr
>> --enable-targets=all --enab
>> le-cld --enable-checking=release --build=i486-linux-gnu
>> --host=i486-linux-gnu --
>> target=i486-linux-gnu
>> Thread model: posix
>> gcc version 4.3.2 (Debian 4.3.2-1.1)
>>
>> Should the target have been i686-linux-gnu if I had the right
>> configuration for it or the right gcc installed?
>>
> reinstall with AM64 architecture.
>
>
>
Reinstall only gcc and other packages or the entire Debian OS?

--
If you desire to respond directly remove the "sj." from the domain name
part of my email address. It is a spam jammer.
From: Artist on 7 Mar 2010 12:09
Darren Salt wrote:
> I demand that Artist may or may not have written...
>
>> Darren Salt wrote:
>>> I demand that Artist may or may not have written...
> [snip]
>>>> I was mistaken about x86_64. The uname -m command gives i686.
>>> Kernel. Not particularly relevant, except that that tells me that it only
>>> supports native 32-bit userland.
>
>>> /proc/cpuinfo is more interesting; particularly the first model name line
>>> and flags line.
>
> [snip]
>> model name : Intel(R) Xeon(R) CPU E5405 @ 2.00GHz
> [snip]
>> flags : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse
>> sse2 ss ht nx constant_tsc pni ssse3 sse4_1
> [snip]
>
> 32-bit. However, according to Intel, that CPU is EM64T; so Debian's -amd64
> kernels should be fine, as should an amd64 install.
>
>> I have executed the command:
>> apt-get remove --purge libevent
>> From the documentation I understand this was supposed to remove all
>> files for libevent. But the command:
>
> All files listed as being installed from the .deb.
>
>> locate libevent
>> finds many files for libevent in the directories:
>> /usr/local/src/libevent-1.4.13-stable/
>> /usr/local/lib/
>> Were these supposed to be removed be apt-get? Or should I remove these
>> manually?
>
> They weren't installed from a .deb, so you'll have to remove them manually.
>
Is it safe to simply delete every file found using the locate command?
Or is there anything like a Windows XP registry that would cause trouble
if I did it that way?

--
If you desire to respond directly remove the "sj." from the domain name
part of my email address. It is a spam jammer.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Logs and dumps for kernel panics to collect and analyze?
Next: resize a lvm volume on a raid1