Hello all,

Recently I became the proud owner of a Lenovo Thinkpad T61 with an Intel Core 2 Duo T7500 processor.

Now what is this for a processor? It is 64 bits? Does it contain two cores?

On all the pages I have googled, it seems that the opinions diverge towards a 64 bits processor. So I should install Lenny AMD64 bit?

If so, does anyone know whether the driver for my NVIDIA NVS 140 still works? The only working version I could find was from Lenovo.com and it was intended for Suse but it worked fine on Debian. As usual with nvidia modules, a module had to be compiled against my own kernel headers. Would that mean that I compiled the source and that it would compile equally well on a 64 bit system? The process is 'user friendly' and hence not completely transparant.

I realize that I should do a complete re-install if I decide to go for AMD64. I do have experience with Lenny AMD64 so that should be no problem. Except for the nvidia as outlined above.

The next question is, is this a dual core machine and do I need an SMP kernel? I don't see it available for Lenny, should I recompile it myself and assert SMP in the config? If so how do I recognize that two cores are running? When I booted the machine just once in Vista (Gawd forbid!) I saw in the processor performance window that there were TWO cores active, just like there were two processors present. But strangely enough, the version was Vista Ultimate [bloatware] 32 bits.

Or is Core 2 duo nothing more than customer cheating where one 64 bit core is being sold as 2 32 bit cores in parallel??

Any advice is highly welcome.

jlinkels

As I'm not a Debian user I'll pass on all those questions.
The core 2 Duo will be two 64-bit cores - "cat /proc/cpuinfo". These days I would think even Debian would ship SMP kernels by default. Use either 32- or 64-bit bit kernel. If 64- bit you may have some issues with 32-bit only code unless the distro is multi-lib. Plugins for browsers for example, although things seem to be better these days.
I only run 64-bit if I have the option.

I'll deal with this first, as its easy; No, it has two 64 bit capable cores. They are genuinely separate cores, and there are genuinely two of them. You are probably thinking of a previous Intel approach (hyperthreading) which looked like two cores, but wasn't (although it did have sort-of advantages...if you have a stupidly long pipeline then having two of them to hide the effect of pipeline stalls can be constructive, sort-of.)

You can also run the cores in 32 bit mode, if you want. I'm not sure that there is any possibility of running one in 32 bit mode and one in 64, but then I'm not sure why you'd want to, apart from sheer cussedness.

Presumably you could, provided you can overcome the 'user friendliness'. Not tried this though.

Yes (and, of course, no). Yes, you need an SMP kernel to make full use of the processor. You'd think a non-smp kernel would also work, just without making the full capability of the processor available, but I've seen this crash immediately.

On the other hand. these days you probably don't have to do all that much to get an SMP kernel - all kernels out of kernel.org these days are smp by default. So unless you are
-using an old distro
-using a distro intended for embedded/real time/something odd
-using one of the special small-size distros (which are often still on 2.4.x kernels to save space)
you probably have what you need 'automagically'

Oh, and if you are a kde user, ksysguard shows the load on the individual cores as does gnome's 'system monitor 2' (but not as well, IMHO, but I'm biased). I think there is a magic incantation in top that gives you the information too (1? l?...you can use man as well as me).

Charming.

All Debian kernels except the -486 kernels are SMP enabled. So that's why you no longer see SMP in kernel names. You could compile your own if you want to build a kernel specifically for the newer Core 2 processor. I do compile my own, but it's never been clear to me whether there's really any performance improvement.

That is all pretty clear. I have copied my existing installation to an unused partition and right now I am in the process of installing the AMD64 version. The Lenny CD I had failed on install, so I have downloaded a new ISO.

If that one fails as well I'll go the same way of installing Etch first and then switch to testing.

I am keeping a blog of the process, so within a few days I am able to share my experiences.

Thanks all

jlinkels

Just for the record:

The CD I had with the Lenny AMD64 version of about 2 months ago failed. Some file number 944 of 945 it could not find.

Then I re-created an USB stick with the latest Lenny ISO on it. It installed the base system without problems. It seemed that the menu options in this new installer were much more than before, not sure. But I could add floppy.floppy=thinkpad which seems to be necessary if you have a Thinkpad. I didn't test it without. I also could add vga=872 to the boot options, which left me with a text screen of 240x68 characters (or something close) and the installer was nice enough to add this to my menu.lst.

There are a few noteworthy other things:

• Most important of all, the NVIDIA driver worked. Downloaded the newest one from nvidia.com. Installed it. Ignored the compiler version warning. Let nvidia change my xorg.conf. Started KDM. Picture! Could not be simpler.
• The first install was based on Etch + a number of packages from Lenny. Although the wireless worked more or less reconnecting or restarting the network was pure hell. I had to manually issue some iwconfig and ifconfig commands. (The problem is well-known in the various forums - the solution not) Now with a fresh install from Lenny wireless works flawlessly.
• With the 64 bits OS the computer seems to run much cooler. The fan is inaudible. I am still wondering why the computer came with Vista 32 bits.
• In the first install I selected "Desktop system" in dselect, which installs Gnome. After that I installed KDM/KDE, and tried about everything to get the KDE login manager and login screen. There are about 5 different recommendations to get that done. None worked, and I stuck with that dreaded GDM login screen. This time I did not install a GUI from dselect, but after the base install was completed I installed the KDE stanza. That gave me the proper login screen.

In short - I can recommend to install Lenny.

jlinkels

Thats because vista 32 bit has already it's share of trouble with drivers and apps and the situation with 64 bit is even worse.

That's probably just because the default power management settings are different. You can probably tweak that with the standard controls and duplicate the behavior of one or the other in one or the other OS versions.

This one thing I have immense trouble getting a handle on...
isn't 64-bit code supposed to contain ALL of the 32-but codeset as a subset (part of) included in it?

This is why I don't understand why people hunt down 64-bit versions for flash for example, when anything 32-bit SHOULD theoretically run under 64-bit OSes. After all, when you run 64-bit, the totality of your machine language code includes both 32-bit and 64-bit instruction set (and even 16-bit x86 instruction set for that matter).

My notions may be a bit antiquated... so could an EXPERT clarify this for me please?

I'm pretty sure that you can run a 32-bit OS under virtual machine software under a 64-bit OS and when the 32-bit OS happens to have control of one CPU, I'm pretty sure that CPU is really in 32-bit mode (unlike the not exactly 32-bit mode used for 32-bit programs in a 64-bit OS).

That might even be a sensible thing to do with the 32-bit Vista mentioned in this thread.

Cost. Microsoft charges more for 64 bit Vista. Whoever bundled the system didn't want to waste any cost. If the buyer either doesn't care 32 bit vs. 64 bit or doesn't know, then the buyer won't pay extra for 64 bit Vista, so why would the seller include the extra cost.

The trick is where to draw the line, especially for something like a plug in.

It is very hard for the OS (or the software package) to support both 32-bit code and 64-bit code running in the same process. A 32-bit process running at the same time as a 64-bit process is easy. Mixing them is not.

Open source build scripts are easiest to run for the "native" architecture. So if you are building a bunch of packages from source for AMD64 architecture for a some distribution, it is easier to build all of them for AMD64 (rather than build a few for i386). So you can expect the browser in a 64bit distribution to be 64bit. So it gets inconvenient (not impossible) if some of the plug ins for the browser were 32 bit. Note the important difference between a plug in and a totally separate program. There is no problem if a totally separate program is 32 bit.