A day or so ago, I flipped the switch and killed off the 586 specific kernel, by making the 686 kernel bootable on older machines. Turns out it isn't that easy however. Rpm will refuse to install the 686 kernel a 586, because it checks the arch..
sudo rpm -ivh kernel-2.6.21-1.3228.fc8.i686.rpm Preparing... ########################################### [100%] package kernel-2.6.21-1.3228.fc8 is intended for a i686 architecture
(Oddly, the 586 kernel uname is reporting itself as 686 already, which I don't quite understand.. Linux equinox 2.6.21-1.3194.fc7 #1 SMP Wed May 23 22:11:19 EDT 2007 i686 i686 i386 GNU/Linux)
Anyway.. To 'solve' this, I think I'm going to have to make the 686 kernel package an 'i386' package.
Does anyone see anything flawed with this approach?
(Modulo problems with yum doing exactarch matches and upgrades being more of a nightmare than usual).
Dave
On Wed, 2007-06-20 at 14:40 -0400, Dave Jones wrote:
A day or so ago, I flipped the switch and killed off the 586 specific kernel, by making the 686 kernel bootable on older machines. Turns out it isn't that easy however. Rpm will refuse to install the 686 kernel a 586, because it checks the arch..
sudo rpm -ivh kernel-2.6.21-1.3228.fc8.i686.rpm Preparing... ########################################### [100%] package kernel-2.6.21-1.3228.fc8 is intended for a i686 architecture
(Oddly, the 586 kernel uname is reporting itself as 686 already, which I don't quite understand.. Linux equinox 2.6.21-1.3194.fc7 #1 SMP Wed May 23 22:11:19 EDT 2007 i686 i686 i386 GNU/Linux)
Anyway.. To 'solve' this, I think I'm going to have to make the 686 kernel package an 'i386' package.
Does anyone see anything flawed with this approach?
(Modulo problems with yum doing exactarch matches and upgrades being more of a nightmare than usual).
so, umm we're going to have users 'ugprading' from kernel.i586 to kernel.i386? Is that right?
-sv
On Wednesday 20 June 2007 14:44:54 seth vidal wrote:
so, umm we're going to have users 'ugprading' from kernel.i586 to kernel.i386? Is that right?
They'd be going from i686 to i386 too it would seem.
My brain just screams that this is confusing, but I'm not coming up with any hard problems yet. Can you do up a scratch build for us to play with Dave?
On Wed, 2007-06-20 at 14:46 -0400, Jesse Keating wrote:
On Wednesday 20 June 2007 14:44:54 seth vidal wrote:
so, umm we're going to have users 'ugprading' from kernel.i586 to kernel.i386? Is that right?
They'd be going from i686 to i386 too it would seem.
My brain just screams that this is confusing, but I'm not coming up with any hard problems yet. Can you do up a scratch build for us to play with Dave?
just so we're clear, yum won't 'upgrade' a kernel from i686 to i386 and let's not even start thinking about what this will mean for kernel modules.
-sv
On Wed, Jun 20, 2007 at 02:48:50PM -0400, seth vidal wrote:
On Wed, 2007-06-20 at 14:46 -0400, Jesse Keating wrote:
On Wednesday 20 June 2007 14:44:54 seth vidal wrote:
so, umm we're going to have users 'ugprading' from kernel.i586 to kernel.i386? Is that right?
They'd be going from i686 to i386 too it would seem.
My brain just screams that this is confusing, but I'm not coming up with any hard problems yet. Can you do up a scratch build for us to play with Dave?
just so we're clear, yum won't 'upgrade' a kernel from i686 to i386 and let's not even start thinking about what this will mean for kernel modules.
Yeah. The alternative is that I un-kill 586, and we continue shipping that forever. (Or we just tell those 38 586 users to go make their own spin).
Dave
On Wed, 2007-06-20 at 15:10 -0400, Dave Jones wrote:
On Wed, Jun 20, 2007 at 02:48:50PM -0400, seth vidal wrote:
On Wed, 2007-06-20 at 14:46 -0400, Jesse Keating wrote:
On Wednesday 20 June 2007 14:44:54 seth vidal wrote:
so, umm we're going to have users 'ugprading' from kernel.i586 to kernel.i386? Is that right?
They'd be going from i686 to i386 too it would seem.
My brain just screams that this is confusing, but I'm not coming up with any hard problems yet. Can you do up a scratch build for us to play with Dave?
just so we're clear, yum won't 'upgrade' a kernel from i686 to i386 and let's not even start thinking about what this will mean for kernel modules.
Yeah. The alternative is that I un-kill 586, and we continue shipping that forever. (Or we just tell those 38 586 users to go make their own spin).
according to what jesse just said we're also talking about it for all of our i686 kernel users, too. Or was that mis-said?
-sv
On Wed, Jun 20, 2007 at 03:21:08PM -0400, seth vidal wrote:
On Wed, 2007-06-20 at 15:10 -0400, Dave Jones wrote:
On Wed, Jun 20, 2007 at 02:48:50PM -0400, seth vidal wrote:
On Wed, 2007-06-20 at 14:46 -0400, Jesse Keating wrote:
On Wednesday 20 June 2007 14:44:54 seth vidal wrote:
so, umm we're going to have users 'ugprading' from kernel.i586 to kernel.i386? Is that right?
They'd be going from i686 to i386 too it would seem.
My brain just screams that this is confusing, but I'm not coming up with any hard problems yet. Can you do up a scratch build for us to play with Dave?
just so we're clear, yum won't 'upgrade' a kernel from i686 to i386 and let's not even start thinking about what this will mean for kernel modules.
Yeah. The alternative is that I un-kill 586, and we continue shipping that forever. (Or we just tell those 38 586 users to go make their own spin).
according to what jesse just said we're also talking about it for all of our i686 kernel users, too. Or was that mis-said?
Yes. because rpm won't install a 686 package on a 586. Whereas i386 will install everywhere obviously
Dave
On Wednesday 20 June 2007, Dave Jones wrote:
On Wed, Jun 20, 2007 at 03:21:08PM -0400, seth vidal wrote:
according to what jesse just said we're also talking about it for all of our i686 kernel users, too. Or was that mis-said?
Yes. because rpm won't install a 686 package on a 586. Whereas i386 will install everywhere obviously
I suppose making it i586 instead of i386 would be slightly less painful.
On Wed, Jun 20, 2007 at 03:10:35PM -0400, Dave Jones wrote:
Yeah. The alternative is that I un-kill 586, and we continue shipping that forever. (Or we just tell those 38 586 users to go make their own spin).
Will they need their own spin, or just need to do a reinstall rather than an upgrade?
On Wed, Jun 20, 2007 at 03:48:33PM -0400, Matthew Miller wrote:
On Wed, Jun 20, 2007 at 03:10:35PM -0400, Dave Jones wrote:
Yeah. The alternative is that I un-kill 586, and we continue shipping that forever. (Or we just tell those 38 586 users to go make their own spin).
Will they need their own spin, or just need to do a reinstall rather than an upgrade?
If we stop building the kernel for them they'll need their own spin.
Dave
On Wed, Jun 20, 2007 at 04:01:23PM -0400, Dave Jones wrote:
Will they need their own spin, or just need to do a reinstall rather than an upgrade?
If we stop building the kernel for them they'll need their own spin.
Dunno about the other 586 users but I'd probably just change distro at that point, and since its easier to keep all boxes on one distro probably move the lot over, except for the RHEL devel boxes.
Alan
Alan Cox wrote:
On Wed, Jun 20, 2007 at 04:01:23PM -0400, Dave Jones wrote:
Will they need their own spin, or just need to do a reinstall rather than an upgrade?
If we stop building the kernel for them they'll need their own spin.
Dunno about the other 586 users but I'd probably just change distro at that point, and since its easier to keep all boxes on one distro probably move the lot over, except for the RHEL devel boxes.
Alan
Sadly, thats probably what I'd do too.
On Wed, Jun 20, 2007 at 06:00:32PM -0400, Alan Cox wrote:
On Wed, Jun 20, 2007 at 04:01:23PM -0400, Dave Jones wrote:
Will they need their own spin, or just need to do a reinstall rather than an upgrade?
If we stop building the kernel for them they'll need their own spin.
Dunno about the other 586 users but I'd probably just change distro at that point
For the sake of 30 or so users, that may be the better option.
and since its easier to keep all boxes on one distro probably move the lot over, except for the RHEL devel boxes.
As entertaining as it is to watch you throw teddies every time something like this comes up, it doesn't really help the situation.
Dave
On Wed, Jun 20, 2007 at 06:22:57PM -0400, Dave Jones wrote:
and since its easier to keep all boxes on one distro probably move the lot over, except for the RHEL devel boxes.
As entertaining as it is to watch you throw teddies every time something like this comes up, it doesn't really help the situation.
Maybe you are the one who should stop throwing fits since you seem to be doing the name calling. I'm being practical and serious. Maintaining two sets of boxes on two distros is a complete and utter pain.
Alan
On Wed, Jun 20, 2007 at 04:01:23PM -0400, Dave Jones wrote:
Yeah. The alternative is that I un-kill 586, and we continue shipping that forever. (Or we just tell those 38 586 users to go make their own spin).
Will they need their own spin, or just need to do a reinstall rather than an upgrade?
If we stop building the kernel for them they'll need their own spin.
But the 686 kernel would be bootable, right? And once you're running that kernel, how does RPM even know to cause trouble?
On Wed, Jun 20, 2007 at 08:26:04PM -0400, Matthew Miller wrote:
But the 686 kernel would be bootable, right? And once you're running that kernel, how does RPM even know to cause trouble?
Ah, never mind. I saw Alan's post.
Matthew Miller wrote:
On Wed, Jun 20, 2007 at 03:10:35PM -0400, Dave Jones wrote:
Yeah. The alternative is that I un-kill 586, and we continue shipping that forever. (Or we just tell those 38 586 users to go make their own spin).
Will they need their own spin, or just need to do a reinstall rather than an upgrade?
I have K6's as servers. Re-installs or re-spins are not really an option for me. And make that 37 users :P
On Wed, Jun 20, 2007 at 04:03:21PM -0400, Bill Nottingham wrote:
Dave Jones (davej@redhat.com) said:
Yeah. The alternative is that I un-kill 586, and we continue shipping that forever. (Or we just tell those 38 586 users to go make their own spin).
Patch RPM. :P
Oh yeah, that's always a good idea ;-) Since my last foray into the rpm source, I have even more respect for pnasrat. I'd drink a lot more if I were in his position.
Dave
On Wed, 20 Jun 2007, Dave Jones wrote:
On Wed, Jun 20, 2007 at 04:03:21PM -0400, Bill Nottingham wrote:
Dave Jones (davej@redhat.com) said:
Yeah. The alternative is that I un-kill 586, and we continue shipping that forever. (Or we just tell those 38 586 users to go make their own spin).
Patch RPM. :P
Oh yeah, that's always a good idea ;-)
We could always encode /proc/cpuinfo + compiler flags used into dependencies and... :)
Since my last foray into the rpm source, I have even more respect for pnasrat. I'd drink a lot more if I were in his position.
Hehe, can I quote you on that (I work on RPM these days with Paul) ;) Oh and btw, RPM 4.4.2.1 will support %patch -F<n> too.
- Panu -
Panu Matilainen <pmatilai <at> laiskiainen.org> writes:
Since my last foray into the rpm source, I have even more respect for pnasrat. I'd drink a lot more if I were in his position.
Hehe, can I quote you on that (I work on RPM these days with Paul) ;)
I've noticed. As a long-time apt-rpm user, I think it's great to have you working on RPM itself. You managed to resurrect apt-rpm at a time where people were giving up on it and implement the 2 most-requested features (multilib and repomd support), the latter also making the issue of repos dropping support for it irrelevant. :-) And now you and Paul are resurrecting the RPM upstream project and cleaning up the huge mountain of bitrot which had formed, and I've noticed you're also working on fixing longstanding annoying bugs like "provides as obsoletes" (already fixed for 4.4.2.1) and "uninstalling multilib package erases files" (fix under discussion). I'd really like to thank you for picking up that thankless job and also for all the work you're doing on the apt-rpm project (looking forward to a stable release with sqlite repomd support), you really deserve those thanks!
Kevin Kofler
On Wed, Jun 20, 2007 at 04:03:21PM -0400, Bill Nottingham wrote:
Dave Jones (davej@redhat.com) said:
Yeah. The alternative is that I un-kill 586, and we continue shipping that forever. (Or we just tell those 38 586 users to go make their own spin).
Patch RPM. :P
The history might be good here actually as I guess Bill is one of the few folks at Red Hat long enough to remember it
gcc produced "686" code that wasn't in fact 686 machine architecture compliant
The gcc team denied this until I quoted them pages from the Intel doc (ok obscure pages but they are there)
It was decided by the gcc folks that it was better to keep gcc 686 including cmov and tell people to use 586 otherwise (there were good performance reasons on original PPro when the decision was made but not by PIV)
A hack was put into rpm to say 686 is "686 + cmov"
It was agreed that rpm needed fixing properly anyway for architecture - notably that architectures should become dependancies anyway as should cpu flags. That somehow never happened
(The reasoning being that a PC would intrinsically supply "686" "686_cmov" etc while a PPC would not, but qemu on ppc could provide "686" and allow 686 binaries to be installed and stuff. It's actually not as bright as it sounds when you think about multiarch, in fact in some ways we should probably be glad it didn't happen ;) )
Anyway fix gcc and you can fix rpm and you get back to the world as intended
On Wed, Jun 20, 2007 at 03:10:35PM -0400, Dave Jones wrote:
Yeah. The alternative is that I un-kill 586, and we continue shipping that forever. (Or we just tell those 38 586 users to go make their own spin).
For FC7 I don't see an easy answer - Fix the 586 kernel to be built 686 -cmov and push it as 586 for testing and verification. For FC8 remove the RPM hack ship real 686 binaries (not GCC '686 and a bit' binaries) and we'll rock.
On Wed, Jun 20, 2007 at 05:56:59PM -0400, Alan Cox wrote:
On Wed, Jun 20, 2007 at 03:10:35PM -0400, Dave Jones wrote:
Yeah. The alternative is that I un-kill 586, and we continue shipping that forever. (Or we just tell those 38 586 users to go make their own spin).
For FC7 I don't see an easy answer
F7 is irrelevant. Given it's already released, it's too late for any change of this nature.
- Fix the 586 kernel to be built 686 -cmov
and push it as 586 for testing and verification.
That's what the current 686 kernel is in rawhide.
For FC8 remove the RPM hack ship real 686 binaries (not GCC '686 and a bit' binaries) and we'll rock.
I'd rather we fixed this without introducing hacks we know we're going to have to later remove.
Dave
On Wed, Jun 20, 2007 at 06:26:20PM -0400, Dave Jones wrote:
For FC8 remove the RPM hack ship real 686 binaries (not GCC '686 and a bit' binaries) and we'll rock.
I'd rather we fixed this without introducing hacks we know we're going to have to later remove.
You are removing an ugly hack not adding one if FC8 removes the rpm cmov ugly
On Wed, 20 Jun 2007 15:10:35 -0400, Dave Jones davej@redhat.com wrote:
Yeah. The alternative is that I un-kill 586, and we continue shipping that forever. (Or we just tell those 38 586 users to go make their own spin).
I'm thinking about getting a new box anyway (it's an old not-quite-C3 with some odd Biblean-sounding codename, chugging along at 800MHz). With less than 40 users, it's just not worth it. I'm surprised though, I thought VIA was more popular than that.
-- Pete
On Wed, Jun 20, 2007 at 05:42:24PM -0700, Pete Zaitcev wrote:
I'm thinking about getting a new box anyway (it's an old not-quite-C3 with some odd Biblean-sounding codename, chugging along at 800MHz). With less than 40 users, it's just not worth it. I'm surprised though, I thought VIA was more popular than that.
It is a good deal more popular than that (although the 686 compatible but not gcc 686 compatible ones are the older ones generally)
Unless Dave can publish data sets and a methodology for his count (and given even the big marketing companies can't do it I want to see this) we should assume he made up a number to justify killing it cos he finds it a hassle to maintain.
Alan
On 6/21/07, Alan Cox alan@redhat.com wrote:
On Wed, Jun 20, 2007 at 05:42:24PM -0700, Pete Zaitcev wrote:
I'm thinking about getting a new box anyway (it's an old not-quite-C3 with some odd Biblean-sounding codename, chugging along at 800MHz). With less than 40 users, it's just not worth it. I'm surprised though, I thought VIA was more popular than that.
It is a good deal more popular than that (although the 686 compatible but not gcc 686 compatible ones are the older ones generally)
Unless Dave can publish data sets and a methodology for his count (and given even the big marketing companies can't do it I want to see this) we should assume he made up a number to justify killing it cos he finds it a hassle to maintain.
Alan
The 38 comes from Smolt:
http://smolt.fedoraproject.org/stats
Did someone say it isn't always detected correctly?
On Thu, Jun 21, 2007 at 06:50:23AM -0500, Dr. Diesel wrote:
The 38 comes from Smolt:
http://smolt.fedoraproject.org/stats
Did someone say it isn't always detected correctly?
Smolt is currently only counting a subset of FC7 users. Lots of us are still using FC6 and the data should be skewed towards bigger/new boxes for early adopter patterns - still useful data for arguing the 586 kernel is relatively low userbase.
On 6/21/07, Alan Cox alan@redhat.com wrote:
On Thu, Jun 21, 2007 at 06:50:23AM -0500, Dr. Diesel wrote:
The 38 comes from Smolt:
http://smolt.fedoraproject.org/stats
Did someone say it isn't always detected correctly?
Smolt is currently only counting a subset of FC7 users. Lots of us are still using FC6 and the data should be skewed towards bigger/new boxes for early adopter patterns - still useful data for arguing the 586 kernel is relatively low userbase.
I really hate to screw people, but you guys have enough work already! Do we really need Fedora 10 to be able to run on a i586?
On Thu, 2007-06-21 at 07:10 -0500, Dr. Diesel wrote:
On 6/21/07, Alan Cox alan@redhat.com wrote:
On Thu, Jun 21, 2007 at 06:50:23AM -0500, Dr. Diesel wrote:
The 38 comes from Smolt:
http://smolt.fedoraproject.org/stats
Did someone say it isn't always detected correctly?
Smolt is currently only counting a subset of FC7 users. Lots of us are still using FC6 and the data should be skewed towards bigger/new boxes for early adopter patterns - still useful data for arguing the 586 kernel is relatively low userbase.
I really hate to screw people, but you guys have enough work already! Do we really need Fedora 10 to be able to run on a i586?
Why not? We're talking about getting Fedora running on ARM and SPARC and Alpha. Make i586 a secondary arch :)
josh
On Thu, 21 Jun 2007 07:32:31 -0500
Why not? We're talking about getting Fedora running on ARM and SPARC and Alpha. Make i586 a secondary arch :)
Lets not do that, I know quite a few people running Fedora on epia's including older ones and I would hate to see Fedor not supporthing those machines anymore. Note I do not have any such a machine left myself.
I think this discussion has been blown both off-topic and out of proportion.
Dave wants to kill of the i585 kernel and still keep supporting i586, which I think is a great idea, ideally we would have / need only one kernel per arch.
However we have this purely technical problem where for current i586 users rpm will not install the i686 kernels even though it can run on i586. Despites rpm's buggy, but documented / relied upon, behaviour of finding an i686 without cmov not an i686 (lets keep that out of the discusuion for now). I find this perfectly logical behaviour of rpm.
Think about it i686 means only runs on i686 and better, so dave's proposed solution of naming it i586 is technically correct.
This does mean however that rawhide i686 users (quite a lot of them) will have to manually install the first kernel update which is called .i586 using rpm -i should work just fine in this case. If we document and announce this I don't see a problem.
As for normal updates, I'm sure anaconda can be thought to fix this. People doing (unssupported) yum updates should once again fix this manually, which again we need to document.
Regards,
Hans
On Thu, 2007-06-21 at 14:55 +0200, Goede, J.W.R. de wrote:
On Thu, 21 Jun 2007 07:32:31 -0500
Why not? We're talking about getting Fedora running on ARM and SPARC and Alpha. Make i586 a secondary arch :)
Lets not do that, I know quite a few people running Fedora on epia's including older ones and I would hate to see Fedor not supporthing those machines anymore. Note I do not have any such a machine left myself.
I think this discussion has been blown both off-topic and out of proportion.
My "suggestion" was merely a joke. I should have used a bigger smiley. Or just kept quiet.
josh
On Thu, 2007-06-21 at 07:58 -0500, Josh Boyer wrote:
On Thu, 2007-06-21 at 14:55 +0200, Goede, J.W.R. de wrote:
On Thu, 21 Jun 2007 07:32:31 -0500
Why not? We're talking about getting Fedora running on ARM and SPARC and Alpha. Make i586 a secondary arch :)
Lets not do that, I know quite a few people running Fedora on epia's including older ones and I would hate to see Fedor not supporthing those machines anymore. Note I do not have any such a machine left myself.
I think this discussion has been blown both off-topic and out of proportion.
My "suggestion" was merely a joke. I should have used a bigger smiley. Or just kept quiet.
It's interesting to see the perception though. The response doesn't seem to match your suggestion.
On 6/21/07, Alan Cox alan@redhat.com wrote:
On Wed, Jun 20, 2007 at 05:42:24PM -0700, Pete Zaitcev wrote:
I'm thinking about getting a new box anyway (it's an old not-quite-C3 with some odd Biblean-sounding codename, chugging along at 800MHz). With less than 40 users, it's just not worth it. I'm surprised though, I thought VIA was more popular than that.
It is a good deal more popular than that (although the 686 compatible but not gcc 686 compatible ones are the older ones generally)
Unless Dave can publish data sets and a methodology for his count (and given even the big marketing companies can't do it I want to see this) we should assume he made up a number to justify killing it cos he finds it a hassle to maintain.
Having watched from the sidelines I updated my VIA mini-ITX system yesterday. Its an original 800 MHz model.
Fedora installs for an i586 on it - 586 kernel etc. However, at least post F7 upgrade (meaning I didn't check beforehand) uname -m and arch report i686. Smolt also sees this as an i686 - in fact the complete profile is at
http://smolt.fedoraproject.org/show?UUID=99ad2cb0-5524-4d7e- b145-1c502ba58e62
For those that prefer raw data the /proc/cpuinfo is:- processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 7 model name : VIA Samuel 2 stepping : 3 cpu MHz : 800.065 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow up bogomips : 1601.17 clflush size : 32
However it will not boot a current i686 kernel - resets immediately.
There are 264 (0.4%) CentaurHauls CPUs in Smolt right now (and obviously upgraders like me would not appear there unless we make the effort). Its not much of a proportion, but there are more users than the i586 figures suggest.
Cheers Nigel.
-- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ]
Nigel Metheringham wrote:
Having watched from the sidelines I updated my VIA mini-ITX system yesterday. Its an original 800 MHz model.
Fedora installs for an i586 on it - 586 kernel etc. However, at least post F7 upgrade (meaning I didn't check beforehand) uname -m and arch report i686. Smolt also sees this as an i686 - in fact the complete profile is at
Whats the right way to determine the arch of the box?
-Mike
On Sat, Jun 30, 2007 at 11:57:39AM -0500, Mike McGrath wrote:
post F7 upgrade (meaning I didn't check beforehand) uname -m and arch report i686. Smolt also sees this as an i686 - in fact the complete profile is at
Whats the right way to determine the arch of the box?
uname -m
However for the "gcc 686" as opposed to "Intel/AMD 686" you must also check that cmov is available. Basically smolt is right gcc is wrong 8)
Alan
Alan Cox wrote:
On Sat, Jun 30, 2007 at 11:57:39AM -0500, Mike McGrath wrote:
post F7 upgrade (meaning I didn't check beforehand) uname -m and arch report i686. Smolt also sees this as an i686 - in fact the complete profile is at
Whats the right way to determine the arch of the box?
uname -m
However for the "gcc 686" as opposed to "Intel/AMD 686" you must also check that cmov is available. Basically smolt is right gcc is wrong 8)
I guess I could look at it another way, what info can I grab so its useful to the developers to make decisions about this stuff :)
-Mike
On Sat, Jun 30, 2007 at 01:51:48PM -0500, Mike McGrath wrote:
I guess I could look at it another way, what info can I grab so its useful to the developers to make decisions about this stuff :)
Depends what DaveJ plans for FC8
For current rpm you want to check that
1. All CPUs report family 6 or higher 2. All CPUs have the cmov flag in their cpuid capability bits
On Sat, Jun 30, 2007 at 07:05:51PM -0400, Alan Cox wrote:
On Sat, Jun 30, 2007 at 01:51:48PM -0500, Mike McGrath wrote:
I guess I could look at it another way, what info can I grab so its useful to the developers to make decisions about this stuff :)
Depends what DaveJ plans for FC8
For current rpm you want to check that
- All CPUs report family 6 or higher
- All CPUs have the cmov flag in their cpuid capability bits
Right now, my plan for F8 is to probably revert the changes I made so far, and reintroduce a 586 build.
Unless someone steps up to do whatever needs to change in rpm/gcc. (The latter, I doubt is really changable without buy-in from the gcc community, which I expect will be opposed to changing defacto behaviour).
Dave
On Sat, Jun 30, 2007 at 01:51:48PM -0500, Mike McGrath wrote:
Alan Cox wrote:
On Sat, Jun 30, 2007 at 11:57:39AM -0500, Mike McGrath wrote:
post F7 upgrade (meaning I didn't check beforehand) uname -m and arch report i686. Smolt also sees this as an i686 - in fact the complete profile is at
Whats the right way to determine the arch of the box?
uname -m
However for the "gcc 686" as opposed to "Intel/AMD 686" you must also check that cmov is available. Basically smolt is right gcc is wrong 8)
I guess I could look at it another way, what info can I grab so its useful to the developers to make decisions about this stuff :)
Isn't all of /proc/cpuinfo transmitted? Maybe a finer grained stats on cpu family/model/flags under the "CPU" tag?
Mike McGrath wrote:
Nigel Metheringham wrote:
Having watched from the sidelines I updated my VIA mini-ITX system yesterday. Its an original 800 MHz model.
Fedora installs for an i586 on it - 586 kernel etc. However, at least post F7 upgrade (meaning I didn't check beforehand) uname -m and arch report i686. Smolt also sees this as an i686 - in fact the complete profile is at
Whats the right way to determine the arch of the box?
you could try rpm -q --queryformat %{ARCH} kernel
Leszek Matok wrote:
Dnia 01-07-2007, nie o godzinie 10:32 +0200, dragoran napisał(a):
you could try rpm -q --queryformat %{ARCH} kernel
Especially on FC6...
... do you mean the bug where anaconda selected the wrong kernel? we could first check if we are >=F7
Lam
On Sat, Jun 30, 2007 at 11:22:02AM +0100, Nigel Metheringham wrote:
On 6/21/07, Alan Cox alan@redhat.com wrote:
On Wed, Jun 20, 2007 at 05:42:24PM -0700, Pete Zaitcev wrote:
I'm thinking about getting a new box anyway (it's an old not-quite-C3 with some odd Biblean-sounding codename, chugging along at 800MHz). With less than 40 users, it's just not worth it. I'm surprised though, I thought VIA was more popular than that.
It is a good deal more popular than that (although the 686 compatible but not gcc 686 compatible ones are the older ones generally)
Unless Dave can publish data sets and a methodology for his count (and given even the big marketing companies can't do it I want to see this) we should assume he made up a number to justify killing it cos he finds it a hassle to maintain.
Having watched from the sidelines I updated my VIA mini-ITX system yesterday. Its an original 800 MHz model.
Fedora installs for an i586 on it - 586 kernel etc. However, at least post F7 upgrade (meaning I didn't check beforehand) uname -m and arch report i686. Smolt also sees this as an i686 - in fact the complete profile is at
However it will not boot a current i686 kernel - resets immediately.
There are 264 (0.4%) CentaurHauls CPUs in Smolt right now (and obviously upgraders like me would not appear there unless we make the effort). Its not much of a proportion, but there are more users than the i586 figures suggest.
I also wonder what the 2.1% i386 are. These can't be true i386, or if they are they can't be 30x as many as i586.
And even though ppc is not expected to be a frontline arch, only 378 boxes? Makes me feel like having a big share of ppc boxes.
On Sun, Jul 01, 2007 at 12:14:20AM +0200, Axel Thimm wrote:
I also wonder what the 2.1% i386 are. These can't be true i386, or if they are they can't be 30x as many as i586.
I'd been wondering if those are qemu/vmware/xen or something similar ?
And even though ppc is not expected to be a frontline arch, only 378 boxes? Makes me feel like having a big share of ppc boxes.
Most users won't be reporting anything
On Sat, Jun 30, 2007 at 07:07:29PM -0400, Alan Cox wrote:
And even though ppc is not expected to be a frontline arch, only 378 boxes? Makes me feel like having a big share of ppc boxes.
Most users won't be reporting anything
Yes, that's the issue with these kind of statistics.
At least for ppc one can get some comparative statistics by checking the ratio of ppc to i386/x86_64 iso downloads. The correcting factor would show how different the black numbers behind the smolt stats are from i386/x86_64 to ppc and use that as a weighing factor for getting improved estimators for ppc.
But for the i586 vs i686 issue we can't find any other stats to compare with smolt.
On Sun, 2007-07-01 at 01:15 +0200, Axel Thimm wrote:
On Sat, Jun 30, 2007 at 07:07:29PM -0400, Alan Cox wrote:
And even though ppc is not expected to be a frontline arch, only 378 boxes? Makes me feel like having a big share of ppc boxes.
Most users won't be reporting anything
Yes, that's the issue with these kind of statistics.
At least for ppc one can get some comparative statistics by checking the ratio of ppc to i386/x86_64 iso downloads. The correcting factor would show how different the black numbers behind the smolt stats are from i386/x86_64 to ppc and use that as a weighing factor for getting improved estimators for ppc.
Not really. Considering that:
1) iso downloads don't take yum upgrades into account, and 2) download statistics in general don't take local mirrors into account
Smolt numbers show the people that voluntarily submit profiles. Download statistics show the number of downloads that hit the main servers. Neither can be used to derive estimators from the other.
josh
Josh Boyer wrote:
Smolt numbers show the people that voluntarily submit profiles. Download statistics show the number of downloads that hit the main servers. Neither can be used to derive estimators from the other.
One of the question is can the figures be used to derive proportionate information from the data set - ie approximately what proportion of people have (say) i586 systems from the rpm point of view. Even if we can get that information out of smolt for the systems reporting to smolt (and by the looks of things the question is rather more complex than uname -m), are i586 boxes equally likely to have enabled smolt reporting as current generation boxes....
Nigel.
On Sun, 2007-07-01 at 09:18 +0100, Nigel Metheringham wrote:
Josh Boyer wrote:
Smolt numbers show the people that voluntarily submit profiles. Download statistics show the number of downloads that hit the main servers. Neither can be used to derive estimators from the other.
One of the question is can the figures be used to derive proportionate information from the data set - ie approximately what proportion of people have (say) i586 systems from the rpm point of view. Even if we can get that information out of smolt for the systems reporting to smolt (and by the looks of things the question is rather more complex than uname -m), are i586 boxes equally likely to have enabled smolt reporting as current generation boxes....
IMO, probably not, because i586 boxes tend to be small boxes, with scarce resources, which tend to be administrated, installed and used differently from "big boxes".
E.g. my >10 years old i586-notebook at home uses a hand-crafted, minimized install-set of packages, with any package which is not necessarily required to run this box having been removed or not even installed. As smolt is non-essential, this machine has never seen smolt.
Also, this machine hasn't seen a "full upgrade" ever since an initial Fedora install (years ago), but had been updated/upgraded using networked command-line yum/apt updates/upgrades.
Ralf
Ralf Corsepius wrote:
Also, this machine hasn't seen a "full upgrade" ever since an initial Fedora install (years ago), but had been updated/upgraded using networked command-line yum/apt updates/upgrades.
Not related to this topic but how well has these upgrades work for you?
Rahul
On Sun, 2007-07-01 at 14:50 +0530, Rahul Sundaram wrote:
Ralf Corsepius wrote:
Also, this machine hasn't seen a "full upgrade" ever since an initial Fedora install (years ago), but had been updated/upgraded using networked command-line yum/apt updates/upgrades.
Not related to this topic but how well has these upgrades work for you?
I've done yum upgrades from FC5 -> FC6 -> F7 on several machines of various architectures. All have worked fine, with perhaps one or two already documented manual fixes needed.
josh
On Sun, 2007-07-01 at 14:50 +0530, Rahul Sundaram wrote:
Ralf Corsepius wrote:
Also, this machine hasn't seen a "full upgrade" ever since an initial Fedora install (years ago), but had been updated/upgraded using networked command-line yum/apt updates/upgrades.
Not related to this topic but how well has these upgrades work for you?
It's the way I've been installing Fedora on all of my machines for years. Sometimes it had worked smoothly, sometimes it hasn't.
FC6->FC7 upgrades using yum/apt and package-cleanup worked comparatively smoothly. Other upgrades before had been a PITA (Esp. upgrading FC5->FC6 had been a real disaster.)
The only major difference between using this procedure on i586s in comparison to better cpus is
* Tightness on resources occasionally hitting very badly: - RAM: yum and apt both bombed out during "upgrades" due to lack of memory. Work-around: manually install packages using rpm/yum/apt. Also critical wrt to RAM: SELinux (autolabel'ing running out of memory!): Work-around: Manually run the SELinux tools or disable SELinux. - CPU-speed: yum and apt are sloooow. "yum update" runs take in the order of hours.
* Limitations of the RH-config tools (No X11 nor Gnome on this machine. IMO, Fedora lacks "usable no-X11 config tools".).
Ralf
On Sat, 2007-06-30 at 19:07 -0400, Alan Cox wrote:
On Sun, Jul 01, 2007 at 12:14:20AM +0200, Axel Thimm wrote:
I also wonder what the 2.1% i386 are. These can't be true i386, or if they are they can't be 30x as many as i586.
I'd been wondering if those are qemu/vmware/xen or something similar ?
Generally those will report what the host CPU really is, as they're "virtualized" but they're still running on the host CPU. Though qemu's software mode may be different. I always run with kqemu, and Windows XP detects the Athlon 64 I'm running on.
On Sun, Jul 01, 2007 at 12:21:06AM -0500, Callum Lerwick wrote:
On Sat, 2007-06-30 at 19:07 -0400, Alan Cox wrote:
On Sun, Jul 01, 2007 at 12:14:20AM +0200, Axel Thimm wrote:
I also wonder what the 2.1% i386 are. These can't be true i386, or if they are they can't be 30x as many as i586.
I'd been wondering if those are qemu/vmware/xen or something similar ?
Generally those will report what the host CPU really is, as they're "virtualized" but they're still running on the host CPU. Though qemu's software mode may be different. I always run with kqemu, and Windows XP detects the Athlon 64 I'm running on.
Well, smolt does keep the database and by correlating vendor and CPU one would get a finer grained picture of the i386 systems. At least VMware offers a BIOS vendor string pointing to itself.
But since there are ~8% VMware system but only ~2% i386 systems, at least 3/4 of the VMware systems cannot report i386.
BTW also quite a high value, VMware guests at 8%? Can we detect xen/qemu guests to have stats on physical vs virtual hosts?
On Saturday 30 June 2007 18:14:20 Axel Thimm wrote:
I also wonder what the 2.1% i386 are. These can't be true i386, or if they are they can't be 30x as many as i586.
I do believe there was a bug early on in smolt where all ix86 systems were detected as i386.
Jesse Keating wrote:
On Saturday 30 June 2007 18:14:20 Axel Thimm wrote:
I also wonder what the 2.1% i386 are. These can't be true i386, or if they are they can't be 30x as many as i586.
I do believe there was a bug early on in smolt where all ix86 systems were detected as i386.
I can confirm this. I'm thinking about deleting profiles prior to a few weeks before the F7 launch that are i386 boxes just to avoid confusion. (they can always re-register)
-Mike
On Sun, Jul 01, 2007 at 10:38:12AM -0500, Mike McGrath wrote:
Jesse Keating wrote:
On Saturday 30 June 2007 18:14:20 Axel Thimm wrote:
I also wonder what the 2.1% i386 are. These can't be true i386, or if they are they can't be 30x as many as i586.
I do believe there was a bug early on in smolt where all ix86 systems were detected as i386.
I can confirm this. I'm thinking about deleting profiles prior to a few weeks before the F7 launch that are i386 boxes just to avoid confusion. (they can always re-register)
BTW I registered some RHEL boxes and they don't show up in "OS" stats.
Axel Thimm wrote:
BTW I registered some RHEL boxes and they don't show up in "OS" stats.
There's a limit at the end of some of those queries (like OS). We're working on caching the queries so we can enable the full stats again (and the devices page) that works just about ready, expect it in the next week or so.
-Mike
On Thu, Jun 21, 2007 at 07:42:55AM -0400, Alan Cox wrote:
Unless Dave can publish data sets and a methodology for his count (and given even the big marketing companies can't do it I want to see this) we should assume he made up a number to justify killing it cos he finds it a hassle to maintain.
http://smolt.fedoraproject.org
Dave
On 6/21/07, Dave Jones davej@redhat.com wrote:
we have to be somewhat careful with regard to interpreting smolt stats for fine-grained decision making, especially since f7 is the first release with it available by default.
On a more personal note, I've been using 586 fc6 installs locally to help me prep LTSP packages for submission to fedora. If you don't mind, I'm going to ping you offlist before I'm ready to submit to make sure I know if 586 is going to be dropped or not to make sure the packages I finally submit have the necessary default script logic for whatever fedora ships.
-jef
On Thu, Jun 21, 2007 at 08:39:47AM -0800, Jeff Spaleta wrote:
mind, I'm going to ping you offlist before I'm ready to submit to make sure I know if 586 is going to be dropped or not to make sure the packages I finally submit have the necessary default script logic for whatever fedora ships.
That surely is something for the Fedora Board to decide ?
On 6/21/07, Alan Cox alan@redhat.com wrote:
On Thu, Jun 21, 2007 at 08:39:47AM -0800, Jeff Spaleta wrote:
mind, I'm going to ping you offlist before I'm ready to submit to make sure I know if 586 is going to be dropped or not to make sure the packages I finally submit have the necessary default script logic for whatever fedora ships.
That surely is something for the Fedora Board to decide ?
decide what? who I talk to for confirmation if a decision is made for F8? Since the bits that dave twiddles is directly affected by whomever makes the decision with regard to publishing a 586 kernel or not.. it seems best to me to confirm with him concerning the fallout of the decision making process.. since i am relying on his bits for my bits.
-jef"it would be best to consider having to talk to me later a fit punishment to dave for starting this thread"spaleta
Am I right in thinking the the i586 and the i686 kernels will be absolutely identical? feature for feature AND bug for bug?
Why not have both?
Possibly have i686 for upgrades/updates only and i586 for new installs? with a message in the release notes/docs/major announcements that by Fn+1 i686 kernel will be removed/merged? (but use different words so as not to get people kicking up a fuss...)
On Thu, Jun 21, 2007 at 11:16:00AM -0800, Jeff Spaleta wrote:
That surely is something for the Fedora Board to decide ?
decide what? who I talk to for confirmation if a decision is made for F8? Since the bits that dave twiddles is directly affected by
Whether FC8 should have support for older processors or not. This isn't just the kernel but several other packages - glibc, openssl that would want to either be fixed along with rpm or converted to 686 only.
It also I believe has fallout for OLPC ?
At 5:09 PM -0400 6/21/07, Alan Cox wrote:
On Thu, Jun 21, 2007 at 11:16:00AM -0800, Jeff Spaleta wrote:
That surely is something for the Fedora Board to decide ?
decide what? who I talk to for confirmation if a decision is made for F8? Since the bits that dave twiddles is directly affected by
Whether FC8 should have support for older processors or not. This isn't just the kernel but several other packages - glibc, openssl that would want to either be fixed along with rpm or converted to 686 only.
It also I believe has fallout for OLPC ?
Dave Jones proposes shipping a single kernel that works with all 686 machines, both the ones Fedora calls 686 and the ones Fedora calls 586, rather than having two separate kernels. There is an issue with a hack in RPM that makes shipping a single kernel a bit annoying, and he asked what to do about it. Jeff Spaleta asked Dave Jones to keep him posted, as Jeff needs to make packaging decisions based on what Dave eventually calls the kernel.
From Dave's original post:
At 2:40 PM -0400 6/20/07, Dave Jones wrote:
A day or so ago, I flipped the switch and killed off the 586 specific kernel, by making the 686 kernel bootable on older machines.
...
From Jeff's request:
At 8:39 AM -0800 6/21/07, Jeff Spaleta wrote: ...
On a more personal note, I've been using 586 fc6 installs locally to help me prep LTSP packages for submission to fedora. If you don't mind, I'm going to ping you offlist before I'm ready to submit to make sure I know if 586 is going to be dropped or not to make sure the packages I finally submit have the necessary default script logic for whatever fedora ships.
Note that Jeff expects that the kernel will work for LTSP.
If you have machines that require a 586 kernel you should ask Dave for one of his new kernels and see if it works on them. If it doesn't work because of how it was compiled, you should tell him. Currently you are panicking without any evidence that you will have any issue at all.
On Thu, 2007-06-21 at 17:09 -0400, Alan Cox wrote:
On Thu, Jun 21, 2007 at 11:16:00AM -0800, Jeff Spaleta wrote:
That surely is something for the Fedora Board to decide ?
decide what? who I talk to for confirmation if a decision is made for F8? Since the bits that dave twiddles is directly affected by
Whether FC8 should have support for older processors or not. This isn't just the kernel but several other packages - glibc, openssl that would want to either be fixed along with rpm or converted to 686 only.
What is it that we stand to gain from dropping i586, again? I appreciate that it seems to have an order of magnitude fewer users than PowerPC, but why do we actually need to drop it?
It also I believe has fallout for OLPC ?
OLPC builds its own kernels.
On Thursday 21 June 2007 20:58:09 David Woodhouse wrote:
What is it that we stand to gain from dropping i586, again? I appreciate that it seems to have an order of magnitude fewer users than PowerPC, but why do we actually need to drop it?
I don't think we're really planning on doing that. Dave is trying to find a way to build a single kernel that will work for /both/ i586 and i686. It sounds like he has one already, but he's running into rpm issues given that it's named i686.
On Thu, 2007-06-21 at 08:39 -0800, Jeff Spaleta wrote:
On 6/21/07, Dave Jones davej@redhat.com wrote:
we have to be somewhat careful with regard to interpreting smolt stats for fine-grained decision making, especially since f7 is the first release with it available by default.
When I installed F7 on the AMD-K6 that I use for a firewall/router, I did a text mode install and didn't install X at all. I don't recall being given the opportunity to contribute to the smolt stats.
Dave
On Fri, Jun 22, 2007 at 07:31:06AM -0500, David G. Mackay wrote:
we have to be somewhat careful with regard to interpreting smolt stats for fine-grained decision making, especially since f7 is the first release with it available by default.
When I installed F7 on the AMD-K6 that I use for a firewall/router, I did a text mode install and didn't install X at all. I don't recall being given the opportunity to contribute to the smolt stats.
Good point -- this means the data is inherently skewed against lower-powered CPUs.
On Thu, Jun 21, 2007 at 12:31:06PM -0400, Dave Jones wrote:
even the big marketing companies can't do it I want to see this) we should assume he made up a number to justify killing it cos he finds it a hassle to maintain.
Yes Dave. Statistical methodology ?
On Wed, Jun 20, 2007 at 02:40:20PM -0400, Dave Jones wrote:
Rpm will refuse to install the 686 kernel a 586, because it checks the arch..
RPM understands that cmov is required for '686' - that is it has hacks built in to compensate for the compiler bug at the heart of this stuff.
Anyway.. To 'solve' this, I think I'm going to have to make the 686 kernel package an 'i386' package.
Does anyone see anything flawed with this approach?
It's not a 386 package - its a 586 package if its 686 without cmov, or for Fedora 8 if we've fixed the compiler bug we can remove the rpm hack...
On Wed, 2007-06-20 at 14:40 -0400, Dave Jones wrote:
A day or so ago, I flipped the switch and killed off the 586 specific kernel, by making the 686 kernel bootable on older machines. Turns out it isn't that easy however. Rpm will refuse to install the 686 kernel a 586, because it checks the arch..
sudo rpm -ivh kernel-2.6.21-1.3228.fc8.i686.rpm Preparing... ########################################### [100%] package kernel-2.6.21-1.3228.fc8 is intended for a i686 architecture
Since the other kernels have their specific names in them, such as ppc, x86-64, ppc64, etc., why can't you use a name for ix86 systems instead of x86? Heck, why not just x86? Will rpm upgrade/install with that over 586, 686, etc?
kernel-2.6.21-1.3228.fc8.intel.rpm kernel-2.6.21-1.3228.fc8.x86.rpm kernel-2.6.21-1.3228.fc8.rpm (leave off the name all together for x86 boxes)
Anything other than intel boxes would have the name, like ppc, x86_64, s390, etc..
Would rpm/yum work with anything of that nature?
On Wed, 2007-06-20 at 17:43 -0500, Mike Chambers wrote:
Since the other kernels have their specific names in them, such as ppc, x86-64, ppc64, etc., why can't you use a name for ix86 systems instead of x86? Heck, why not just x86? Will rpm upgrade/install with that over 586, 686, etc?
We'd have to add the new arch to rpm, yum, etc so that it would be known and where it falls in the ordering, etc
Jeremy
On Wed, 2007-06-20 at 18:43 -0400, Jeremy Katz wrote:
On Wed, 2007-06-20 at 17:43 -0500, Mike Chambers wrote:
Since the other kernels have their specific names in them, such as ppc, x86-64, ppc64, etc., why can't you use a name for ix86 systems instead of x86? Heck, why not just x86? Will rpm upgrade/install with that over 586, 686, etc?
We'd have to add the new arch to rpm, yum, etc so that it would be known and where it falls in the ordering, etc
How hard would that be, for it to work with Fedora (if that is an option to use), and to be used on other distros, and still work with their system, if they use the current methods?
And if it's not that hard to implement, is that something worth using then?
Mike Chambers (mike@miketc.com) said:
How hard would that be, for it to work with Fedora (if that is an option to use), and to be used on other distros, and still work with their system, if they use the current methods?
And if it's not that hard to implement, is that something worth using then?
It's something that would need carried forward eternally for this one-time change.
Bill
ons 2007-06-20 klockan 14:40 -0400 skrev Dave Jones:
Anyway.. To 'solve' this, I think I'm going to have to make the 686 kernel package an 'i386' package.
Wouldn't it be more correct to call it i586?
Many FC6 users are on i586 kernels anyway so a yum upgrade would actually do the right thing in this case. :)
/abo
Once upon a time Wednesday 20 June 2007, Dave Jones wrote:
A day or so ago, I flipped the switch and killed off the 586 specific kernel, by making the 686 kernel bootable on older machines. Turns out it isn't that easy however. Rpm will refuse to install the 686 kernel a 586, because it checks the arch..
sudo rpm -ivh kernel-2.6.21-1.3228.fc8.i686.rpm Preparing... ########################################### [100%] package kernel-2.6.21-1.3228.fc8 is intended for a i686 architecture
(Oddly, the 586 kernel uname is reporting itself as 686 already, which I don't quite understand.. Linux equinox 2.6.21-1.3194.fc7 #1 SMP Wed May 23 22:11:19 EDT 2007 i686 i686 i386 GNU/Linux)
Anyway.. To 'solve' this, I think I'm going to have to make the 686 kernel package an 'i386' package.
Does anyone see anything flawed with this approach?
(Modulo problems with yum doing exactarch matches and upgrades being more of a nightmare than usual).
I dont particularly care what the kernel is called but im looking at buying a system from http://www.soekris.com/ to use as wireless access point / firewall / router . its a 586 class cpu so i would really like to have fedora working on it.
Dennis