AMD Sempron 2600 debian installs 386 kernel by default

MrInept · 11-06-2005, 05:48 PM

hi i'm just wondering, when i installed debian, it never gave me the option to install the 686 kernel... why? So I'm wondering is my cpu 686ish? Secondly should i bother installing it (is there much difference)? Thirdly, how do i install it?

zzak · 11-06-2005, 06:11 PM

From Linux Format mag
November, 2005, page 65:

Rebuild the kernel for your cpu:
"it's well worth having a kernel tuned for your
processor. This, together with an optimised glibc,
makes a system snappier than the generic 386 support

...You'll have to obtain the kernel source for your
distro (or a standard release from http://kernel.org)
and then build it. A quick Google search will find
a kernel compilation guide for your distro....when
you are at the configuration phase, drop into the
Processor Type And Features section where you'll need
to select your CPU type from the Processor Family menu,
then recompile, install and reboot"

spooon · 11-06-2005, 07:20 PM

Quote:

Originally posted by MrInept
hi i'm just wondering, when i installed debian, it never gave me the option to install the 686 kernel... why? So I'm wondering is my cpu 686ish? Secondly should i bother installing it (is there much difference)? Thirdly, how do i install it?

It's not only 686, it's also K7. Do "apt-get install kernel-image-2.6-k7" or something like that.

MrInept · 11-07-2005, 04:57 AM

Quote:

Originally posted by spooon
It's not only 686, it's also K7. Do "apt-get install kernel-image-2.6-k7" or something like that.

OMG... How on earth do i upgrade to that... What's the easiest way? I just re-installed so i'ts not much trouble to download everything again. unless there is an easier way. Why doesn't debian put this as an option?

EDIT: Do I have a 64-bit CPU?

pevelius · 11-07-2005, 05:25 AM

you don´t have to reinstall anything. just do this:

apt-get update
apt-get install the_name_of_the_kernel_package_you_want

you can have as many kernels as you like. they are automagically added to grub boot dialog. after you confirm that the kernel you want works, you can remove those you don´t need by

apt-get remove the_name_of_the_kernel_package_you_want_to_remove

you can also use the synaptic package manager gui to install/remove kernels

it might be an option during install, have you checked what you can do by entering additional parameters on the command prompt before starting install?

however, installing kernels is so easy in debian, that i don´t see the point including them all in the basic system installation disk.

Ruben2 · 11-07-2005, 12:59 PM

Quote:

Originally posted by MrInept
OMG... How on earth do i upgrade to that... What's the easiest way? I just re-installed so i'ts not much trouble to download everything again. unless there is an easier way. Why doesn't debian put this as an option?

EDIT: Do I have a 64-bit CPU?

No, Sempron is no 64-bit CPU.
Installing kernels on Debian is a very easy job. Do it like Prevelius says, but if you don't know which kernel you should use, try dselect, aptitude or synaptics (I prefer dselect over aptitude and synaptics myself though) and look for the correct kernel. The descriptions says for which processors it's optimized. I guess you'll need the k7. I'm not sure but it's definitely not the 686, that one is for Pentium processors.

Good luck,
Ruben

brainiac · 11-07-2005, 06:42 PM

Hey, thanks to the tips herein I am now running the 2.6.8-k7 kernel with nvidia support. It works great. Seems to boot and run faster. Thanks again.

MrInept · 11-08-2005, 08:08 AM

Well I got it working. (!) It was a little tricky but with a little guess work it works. I';m posting my menu.lst contents to help others.

Basically, if you can't be bothered reading, i had two problems first of all, this whole AMD thing which is the title of post; second was the booting problem. I have windows xp, on a master drive (hda) and on the primary slave i have linux (hdb) 80GB and 20GB respectively. So I wanted to leave windows untouched and boot from hdb so that the default would be to boot windows and my sister and mum wouldn't notice it. The prob is by setting the slave to first boot priority the bios tells everything it is the first hard drive and the other the second which causes all kind of probs. So what did I do?

I downloaded my new k7 kernel. Perfect. Then I did a update-grub (taking my floppy out of the drive!). Then I went in to grub menu.lst (in /boot/grub/) and changed the numbers around so that where it said linux and hd1 and changed it to hd0. NOTE THAT I DIDN'T CHANGE THE HDB'S TO HDA'S! The same applies for the opposite case (0s to 1s). This booted linux no worries but refused to boot windows for some reason so i found some code by searching around the forums something about mapping when you do this. and here it is:

Code:

# menu.lst - See: grub(8), info grub, update-grub(8)
#            grub-install(8), grub-floppy(8),
#            grub-md5-crypt, /usr/share/doc/grub
#            and /usr/share/doc/grub-doc/.

## default num
# Set the default entry to the entry number NUM. Numbering starts from 0, and
# the entry number 0 is the default if the command is not used.
#
# You can specify 'saved' instead of a number. In this case, the default entry
# is the entry saved with the command 'savedefault'.           
default		5

## timeout sec
# Set a timeout, in SEC seconds, before automatically booting the default entry
# (normally the first entry defined).
timeout		2

# Pretty colours
color cyan/blue white/blue

## password ['--md5'] passwd
# If used in the first section of a menu file, disable all interactive editing
# control (menu entry editor and command-line)  and entries protected by the
# command 'lock'
# e.g. password topsecret
#      password --md5 $1$gLhU0/$aW78kHK1QfV3P2b2znUoe/
# password topsecret

#
# examples
#
# title		Windows 95/98/NT/2000
# root		(hd1,0)
# makeactive
# chainloader	+1
#
# title		Linux
# root		(hd0,1)
# kernel	/vmlinuz root=/dev/hda2 ro
#

#
# Put static boot stanzas before and/or after AUTOMAGIC KERNEL LIST

### BEGIN AUTOMAGIC KERNELS LIST
## lines between the AUTOMAGIC KERNELS LIST markers will be modified
## by the debian update-grub script except for the default options below

## DO NOT UNCOMMENT THEM, Just edit them to your needs

## ## Start Default Options ##
## default kernel options
## default kernel options for automagic boot options
## If you want special options for specifiv kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
# kopt=root=/dev/hdb1 ro

## default grub root device
## e.g. groot=(hd0,0)
# groot=(hd1,0)

## should update-grub create alternative automagic boot options
## e.g. alternative=true
##      alternative=false
# alternative=true

## should update-grub lock alternative automagic boot options
## e.g. lockalternative=true
##      lockalternative=false
# lockalternative=false

## altoption boot targets option
## multiple altoptions lines are allowed
## e.g. altoptions=(extra menu suffix) extra boot options
##      altoptions=(recovery mode) single
# altoptions=(recovery mode) single

## controls how many kernels should be put into the menu.lst
## only counts the first occurence of a kernel, not the
## alternative kernel options
## e.g. howmany=all
##      howmany=7
# howmany=all

## should update-grub create memtest86 boot option
## e.g. memtest86=true
##      memtest86=false
# memtest86=true

## ## End Default Options ##

title		Debian GNU/Linux, kernel 2.6.8-2-k7 
root		(hd0,0)
kernel		/boot/vmlinuz-2.6.8-2-k7 root=/dev/hdb1 ro 
initrd		/boot/initrd.img-2.6.8-2-k7
savedefault
boot

title		Debian GNU/Linux, kernel 2.6.8-2-k7 (recovery mode)
root		(hd0,0)
kernel		/boot/vmlinuz-2.6.8-2-k7 root=/dev/hdb1 ro single
initrd		/boot/initrd.img-2.6.8-2-k7
savedefault
boot

title		Debian GNU/Linux, kernel 2.6.8-2-386 
root		(hd0,0)
kernel		/boot/vmlinuz-2.6.8-2-386 root=/dev/hdb1 ro 
initrd		/boot/initrd.img-2.6.8-2-386
savedefault
boot

title		Debian GNU/Linux, kernel 2.6.8-2-386 (recovery mode)
root		(hd0,0)
kernel		/boot/vmlinuz-2.6.8-2-386 root=/dev/hdb1 ro single
initrd		/boot/initrd.img-2.6.8-2-386
savedefault
boot

### END DEBIAN AUTOMAGIC KERNELS LIST

# This is a divider, added to separate the menu items below from the Debian
# ones.
title		Other operating systems:
root


# This entry automatically added by the Debian installer for a non-linux OS
# on /dev/hda1
title Windows
map (hd0) (hd1)
map (hd1) (hd0)
root (hd1,0)
savedefault
chainloader +1

Done. note about the changes to windows with map. i honestly don't understand this and my limited programming experience tells me that the two map lines should do nothing but obviously the GRand Unified Bootloader works in mysterious ways! Good Luck!

dastrike · 11-08-2005, 08:54 AM

Debian always installs a -386 kernel during installation for 32-bit x86 systems
You can install a more optimized kernel as shown earlier in this thread by a simple apt-get install kernel-image-... Worth noting is that in Debian testing/unstable the packages are called linux-image-... instead though.
The closest suitable one for the 32-bit AMD Sempron processors are the -k7 suffixed kernels (there are 64-bit Semprons as well on Socket 754, but not all of them have the 64-bit extensions enabled. All Socket A Semprons are 32-bit only)

MrInept · 11-08-2005, 03:56 PM

I think its pretty amazing (or sad) that a cpu has changed so little in 20 odd yrs that a 386 effectively does all the same things... in the same way

dastrike · 11-09-2005, 12:14 PM

Quote:

Originally posted by MrInept
I think its pretty amazing (or sad) that a cpu has changed so little in 20 odd yrs that a 386 effectively does all the same things... in the same way

Well, the thing that has kept x86 around has been backwards compatibility - the massive base of existing x86 software is something that has been a heavy factor not to steer away from it.

The x86 processors of today are quite different beasts compared to the 386. Current-day x86 processors translate the CISC instructions of x86 in hardware to an internal RISC format which allows for better performance.

Intel tried to move away from x86 with their IA-64 (Intel Itanium, Itanium2) but that never gained any widespread support and is currently placed in a narrow niche of high-performance computing - which is far from the wide niche that Intel intended for it. The IA-64 was undermined also by AMD's AMD64 which is as we all know by now is a 64-bit extension of the x86 instruction set (similar to the Intel 80386 introduced a 32-bit extension of the original 16-bit x86). And finally Intel caved in and added AMD64 support (calling it EM64T) to their x86 processor lines too.
So the market's need of backwards compatibliity due to the massive installed base of x86 is so huge that not even the behemoth Intel succeeded in breaking that trend with their IA-64 architecture.

MrInept · 11-09-2005, 06:12 PM

Interesting. Why has the advance in processors always been in cycle speeds ie mhz ghz rather than bits? Why is the trend to change from 16 to 32 to 64 so slow, seeing as backwards compatibility is possible?

dastrike · 11-11-2005, 05:14 PM

Quote:

Originally posted by MrInept
Interesting. Why has the advance in processors always been in cycle speeds ie mhz ghz rather than bits? Why is the trend to change from 16 to 32 to 64 so slow, seeing as backwards compatibility is possible?

The "bitness" of processors has very little to do with the immediate performance. In fact the performance gets slightly worse when increasing it if no other changes are made. E.g. the transition from 32-bit to 64-bit means that every pointer gets doubled in size. This means the memory usage increases slightly, which also means the cache misses will increase since slightly less effective data fits there assuming the same cache sizes are maintained.

The overall higher performance of AMD64 processors in 64-bit mode compared to the same processor in 32-bit mode comes not from the 64-bitness, but from another thing: the eight additional general purpose registers, and eight additional XMM SIMD registers that are only available in the 64-bit mode. x86 is a quite register-starved architecture so doubling the amount of GPRs and vector registers can give a noticeable boost in certain cases.

The bitness of processors comes with the need. Back in early 80's 16 bits was enough. Programs were small and could typically fit without problems in the 64 KiB (2^16 = 65,536 bytes) large addressing window.
With time the memory in systems increased and applications bloated in size. Suddenly the 64k window was too small for many applications and cumbersome segmentation had to be used to access more memory - basically you use a 64 KiB large window and slide it across the entire memory. Annoying to deal with and the performance is poor with that.
So in comes the 32-bit systems that could linearly address up to 4 GiB (2^32 = 4,294,967,296 bytes). Quite a step up. It took ten years though for the most common x86 operating system to go over to 32-bitness. The Intel 386 was released in 1985, Windows 95 (which still had quite a lot of 16-bit stuff left, but had most stuff in 32-bit) was released in, well 1995.

Fast forward to late 90's. Many high-end applications (e.g. database stuff) are getting close to and above the 4 GiB barrier (note that the actual limit is 2-3 GiB since operating systems tend to reserve the highest 1-2 GiB of the virtual memory for themselves). The icky procedure of segmentation is again brought out, the size of the segments is a bit manageable though - a 4 GiB window to slide around. But still it makes for cumbersome programming and poor performance.
So the x86 is extended yet again, by AMD this time around though. 64-bit addressing can linearly address up to a breathetaking 16 EiB (exbibytes) = 17,179,869,184 GiB. Yikes. The AMD's current implementation supports "only" 48-bit virtual addressing (up to 256 TiB = 262,144 GiB) and 40-bit physical addressing (up to 1 TiB = 1,024 GiB)

So the memory usage is what drives the "bitness" upwards.

The fairly commonly heard argumentation that 64-bit math gets faster with 64-bit processors is a bit flawed, as floating-point math on the x86 has been 80-bit since the i387, and is currently 128-bit when using SSE2. And integer math has been able to be done quickly in 64-bit ever since MMX, so the performance improvement of traditional integer math has a very very small impact, since any high-performance-requiring 64-bit integer math tasks have been able to be used through the MMX for a better part of the past ten years.