CentOS - Jun 2005 - CentOS 4.0 -> 4.1 update failing

I've updated CentOS 4.0 to 4.1 on several machines (some desktops, some 
servers).  However on my laptop, update is failing with following error 
just after headers are downloaded:

--> Running transaction check
--> Processing Dependency: glibc-common = 2.3.4-2 for package: glibc
--> Finished Dependency Resolution
Error: Missing Dependency: glibc-common = 2.3.4-2 is needed by package glibc

My CentOS.repo is a standard one, as distributed with CentOS.  I don't 
have any additional repos defined on my laptop.  I attempted to clear 
yum cache (rm -rf /var/cache/yum/*).  Rerun yum update, and got the same 
error again.

Looking at the /var/cache/yum/base/headers, I see that yum downloaded 
headers for gblic-common, glibc-devel, and glibc-headers, but not for 
glibc.  Seems as if yum did not considered base glibc package to be due 
for update.  Running rpm -q glibc, shows that currently installed 
version of glibc is 2.3.4-2 (and all the other currently installed glibc 
packages are at the same version level).

I don't remember doing anything fancy on that laptop that could have 
triggered this problem.  Basically, it was normal install (desktop+devel 
packages mostly), and after that it was regulary updated from cron.

Of course, as a workaround I could download glibc and related packages 
and update it by hand, and than rerun yum update to get all other 
updates from 4.1.  But, I though it would be more fun if anybody could 
give me hint or two why yum failed to update this particular system.

On Mon, Jun 20, 2005 at 12:05:47AM -0500, Aleksandar Milivojevic enlightened
us:
> I've updated CentOS 4.0 to 4.1 on several machines (some desktops, some
> servers).  However on my laptop, update is failing with following error 
> just after headers are downloaded:
> 
> --> Running transaction check
> --> Processing Dependency: glibc-common = 2.3.4-2 for package: glibc
> --> Finished Dependency Resolution
> Error: Missing Dependency: glibc-common = 2.3.4-2 is needed by package
glibc
> 
> My CentOS.repo is a standard one, as distributed with CentOS.  I don't 
> have any additional repos defined on my laptop.  I attempted to clear 
> yum cache (rm -rf /var/cache/yum/*).  Rerun yum update, and got the same 
> error again.
> 
> Looking at the /var/cache/yum/base/headers, I see that yum downloaded 
> headers for gblic-common, glibc-devel, and glibc-headers, but not for 
> glibc.  Seems as if yum did not considered base glibc package to be due 
> for update.  Running rpm -q glibc, shows that currently installed 
> version of glibc is 2.3.4-2 (and all the other currently installed glibc 
> packages are at the same version level).
> 
> I don't remember doing anything fancy on that laptop that could have 
> triggered this problem.  Basically, it was normal install (desktop+devel 
> packages mostly), and after that it was regulary updated from cron.
> 
> Of course, as a workaround I could download glibc and related packages 
> and update it by hand, and than rerun yum update to get all other 
> updates from 4.1.  But, I though it would be more fun if anybody could 
> give me hint or two why yum failed to update this particular system.
I had the same problem on a Pentium 166 machine. Is the laptop an i586
architecture? I am wondering if there is some exactarch weirdness going on
with yum. I needed to get the machine up and running, so I did as you said
and installed glibc and glibc-common by hand, then re-ran yum. 

Matt

-- 
Matt Hyclak
Department of Mathematics 
Department of Social Work
Ohio University
(740) 593-1263
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.centos.org/pipermail/centos/attachments/20050620/97ebe0ac/attachment-0003.sig>

Matt Hyclak wrote:
> I had the same problem on a Pentium 166 machine. Is the laptop an i586
> architecture? I am wondering if there is some exactarch weirdness going on
> with yum. I needed to get the machine up and running, so I did as you said
> and installed glibc and glibc-common by hand, then re-ran yum. 
Yes, it is an Pentium MMX 233 (i586).  All the other machines where 
update was successfull were i686.

From: Johnny Hughes <mailing-lists at
hughesjr.com>
> RedHat doesn't support i586 support at all with CentOS-4 ... not via
the
> kernel or glibc.  CentOS (starting with version 3.3) built an i586 kernel.
> CentOS-4 continued this support.
> One way to support this would be to use the i386 version.  Seems like what
> RH recommended on the upstream bug I submitted.
I'm sure, based on my prior conversation with Cox, that Red Hat really
has absolutely _no_ interest in supporting i586 out of sheer marketshare.
It's either i486 (i386) or i686 for them.

Unlike i486 and i686, i586 is a _specific_ (and partially buggy**) product --
namely original Pentium and Pentium MMX products and _no_ other.
All subsequent Intel products (Pentium Pro on-ward) have been i686.
And _all_ clones, cores, etc... have either been i486 or i686 ISA compatible.

[ **NOTE:  I'm not talking about the FPU bug.  That was minor compared
to many of its other bugs and, even worse, some real design flaws in the
ALU and control. ]


--
Bryan J. Smith   mailto:b.j.smith at ieee.org

From: Johnny Hughes <mailing-lists at
hughesjr.com>
> Right ... but in a software capacity we are also talking about pentium,
> pentium mmx, cyrix i686, amd k6, via c3 that use i586 packages.  
No!  You _never_ want anything but a _true_ Pentium or Pentium MMX
using i586.  i586 ISA and/or optimization are _not_ good for anything
but those 2 chips.

You want to use i686 for AMD K6, Cyrix M2 and Via C3.
You want to use i486 for AMD K5 and Cyrix 6x86/M1.

This is one of the most misunderstood details in the user world.
> CentOS is trying to provide limited support for them.  This support
> doesn't in any way affect other packages like glibc.i686 or the i686
> kernels ... In case someone might be concerned about a CentOS / RHEL
> divergence.  The i586 packages are only installed on machines that have
> i586 processors ...
I understand that.  But the point you are missing is that there are
_only_2_ "i586 ISA" processors:  Pentium and Pentium MMX
Do not confuse "i586 class" with "i586 ISA."

I appreciate that CentOS offers these added processors, since Red Hat
does not consider it their bother -- whether they only ship i486 and
i686, or just i686 now (since all designs of the mid-to-late '90s are
i686 ISA).
> if you have i686 then that is what is installed on your machine.
I understand.  
> Red Hat did seem open to at least reviewing a patch to the glibc
> package that provides i586 support if we get it working.
And that's great.  But I'm sure the marketshare is why they didn't
do it themselves.

Right now, the market is:
  i686 ISA compatible > i486 ISA compatible > i586 ISA compatible

And it's been like that for awhile.  But even before then, it's
_always_ been:  

  i486 ISA compatible > i586 ISA compatible

i586 is not recommended, even if i686 ISA compatible typically means
i586 is supported.  It's just rather poor performing, and you can
occassionally run into a serious instruction issue (especially with
early i686 clones that did i686 fine, but not always i586).

There is _no_ "i586 clone" -- no one would purposely clone the
Pentium's instruction set because it was quickly superceded by
i686 for good reasons.  Unfortunately, Intel took forever to get
past its Pentium Pro offering, which was never designed for
consumers, and finally offer an i686 for consumers in the Pentium II.

Hence why i686 clones like the AMD K6 actually pre-date much of
the widespread consumer adoption of an i686 from Intel itself because
the consumer chip didn't hit for years after its first ISA.

idSoftware always had excellent commentary on i586 v. i686, largely
because they found some of the best hacks for i586 to get around
many of its ALU design flaws.



--
Bryan J. Smith   mailto:b.j.smith at ieee.org

From: Matthew Miller <mattdm at mattdm.org>
> I think it goes something like this: "Bu.... bigger number... bigger
> number faster! Want bigger number!" :)
Never confuse marketing with actual ISA compatibility and optimization.

Consider an i586 ISA target (--march=i586) or ISA optimization
(--mopt=i586) a _de-optimization_ for i686 ISA compatible processors.
And that include's Intel's own Pentium Pro/II, III/M, 4, etc...

Just because it's higher doesn't necessarily mean better.  Heck, Intel
is going back to the P3 core because the P4 core isn't scaling, and it
was a really quick hack that has poor ALU and FPU performance MHz
for MHz compared to the PPro-P3 design.


--
Bryan J. Smith   mailto:b.j.smith at ieee.org

From: Dan Pritts <danno at internet2.edu>
> I read a web page that suggested that in some cases software built for
> "i686" would not in fact work on Via C3 processors (this is near
& dear
> to my heart since i just bought a motherboard based on one).  The C3
> is definitely a modern platform - it's not fast by modern standards but
it
> works well enough for many applications and its heat/power requirements
> are wonderful (circa 10 watts).  
It all depends how you define "modern."

The IDT-Centaur team found that it was very easy to build a chip that
dedicated more transistors to a larger cache that get into a lot of pipeline
optimizations, out-of-order execution, etc...  They were able to build the
WinChip in 18 months -- instead of 36+ for a traditional design.  The
first design also ran on standard 3.3V CMOS and was quite a bit more
tolerant of variances.

Cyrix did similar with the design of the M2/Geode.  The C3 is ViA's
evolution of the WinChip-M2 line, in a Socket-370 package for Intel
GTL+ under official license from Intel.  As much as non-x86 platforms
promise more performance for lower power, it's hard to best some of
the low-power designs of the x86 world at their economies of scale.
> The discussion suggested that the "cmov" instruction was the
problem.
Yes, the "cmov" instruction is an optional i686 instruction in
Intel's
own documentation.  ViA (possibly both Cyrix and IDT-Centaur too)
probably thought it was either a waste of transistors or, more likely,
a timing nightmare to integrate into the ALU/control.  In fact, if
it was considered optional, it sounds like an engineer realized that
it could have design impact when the i686 ISA was written (probably
in advance of the actual release of the Pentium Pro, or in consideration
of Intel's own, future i686 designs).

<flammage=on>
Intel continues to be the poster child for 1970s CS thought when it
comes to overbloat of an already CISC pig.  Ironically, at one time,
they partnered with Digital on the Alpha chip, which is definitely the
most over-anal of RISC architectures.  I.e., if it could hold up timing,
it didn't go in the AXP ISA -- and they were extremely anal on this
to the point of not even including an 8 or 16-bit LOAD/STOR (although
Digital finally caved in this in 21164 -- but all other 8/16-bit data
operations were always left out).
</flammage>

The GCC i686 target, unfortunately, assumes it always exists.
I can semi-understand the logic, because for a run-time to always test
would add a a number of bytes to every single program.
And the software workaround takes over 100x more clock cycles.
> I, of course, had similar upgrade problems to the original poster.  
> I don't really care about the performance optimizations from
"i386"
> to "i686" as long as i'll continue to have something that
works.
i486 was liberally licensed by Intel under reasonable terms after a US
court said numbers could not be trademarked (Intel was hoping to
make money on trademark licensing in conjunction).

i686/GTL+ was only licensed by ViA, although I'll assume the lack of
a cmov instruction in Cyrix/IDT-Centaur designs pre-dates that license.
> One additional interesting data point.  The CentOS 4.0 installer
> gave me the "i586" glibc and the "i686" kernel.  I
would hope that
> this would be consistent.
That's not what you want.  You want to drop down to a i486 instead
of running i586.

Here's a general guide:  

--march=i486

Runs well on a non-superscalar i486, obviously.
Runs fairly well on a super-scalar ix86 that does i486, although
optimizations for the specific architecture should be used.
Portions may run like crap oni586 (true Pentium/MMX), especially
ALU control.

--march=i486 --mtune=i686

Still runs well on a non-superscalar i486 because superscalar
optimizations don't affect it.
Runs near-optimal on a superscalar ix86 that has at least the
same 7-issue core of the Pentium Pro-P3 (2+2+3 ALU+FPU+control).
Even more likely to run like crap on i586 because it assumes the ALU
is 2-issue and well-designed, and i586's just ain't anywhere near
'dat!

--march=i486 --mtune=i586 (or --march=i586)

Improves performance of many operations singificantly on i586.
On i486 (if --march=i486, --march=i586 will not run) and i686,
will use the chip rather inefficently.

E.g., (and this is just 1 example) generated machine code will
ripple integers through what it assumes is a pipelined FPU.
On an i486 or anything but an Athlon clone, this will not only tie up
the FPU, but significantly and artifically delay integer loads.
On a true Intel i686 or AMD Athlon, it will leave the 2 and 3 ALU
pipes, respectively, unused.
Worse yet, the original Nx586 (through the Athlon) is 3x faster at
ALU loads than i586, and it is a clear "de-optimization"

And that's just 1 example.  ;->

--march=i686

Offers little performance gain over --march=i486 --mtune=i686,
while not running at all on an i486 or i586.

--march=i486|i686 --mtune=pentium4

Offers not only improved performance on the Pentium 4, but
all Athlons as well.

--march=i486|i686 --mtune=athlon

This option has been widely debated.  It really _kills_ Intel
performance because Intel i686's 2+2 (ALU+FPU) is not going to
handle optimizations for AMD Athlon's 3+3 (ALU+FPU) and is
going to have lots of stalls (especially on Pentium 4, don't get
me started ;-).  At the same time, the Athlon benefit is
debatable for general applications -- although engineering and
scientific _will_ see a good boost (40% is not uncommon).

The reason why is simple.  Intel's 1 complex _or_ 2 ADD FPU
only allows 1 MULT at full 64-bit precision (and not SSE "lossy
math") whereas AMD's 2 complex _and_ 1 ADD/MULT allows
3 MULT at full 64-bit precision.

Plus, today, you're typically going to be running Athlon64/Opteron,
and you get such "optimizations for free" on x86-64 targets.

SIDE NOTE:
-O3 ... _never_ run -O3 with --march=pentium3, pentium4 or
athlon.  You're asking for "lossy math" in the case of the former,
and unstable optmizations in the case of the latter.  It should _only_
be used when you developed the application and know what you're
doing.


--
Bryan J. Smith   mailto:b.j.smith at ieee.org

From: Johnny Hughes <mailing-lists at
hughesjr.com>
> That is by design ... the i686 glibc will not work with the c3 ... the
> i686 kernel will.
Interesting.  Hmmm.
> You need to use the i386 glibc.  As written, the latest RH glibc SRPM
> will not build for --target i486 or --target i586 ...
But I've seen several packages where building for --target i386
still results in an --march=i486.  In fact, that's probably why they
clearly still say ".i386.rpm" despite requiring i486 ISA.
> I am close to making it build properly for --target i586, but since
> the .i386 glibc works well on i586 and it should build with that
> target unmodified in the future, that is the way we will proceed.

--
Bryan J. Smith   mailto:b.j.smith at ieee.org

From: Johnny Hughes <mailing-lists at
hughesjr.com>
> All of that is probably true ... but the optimizations are already set
> by default by the config.guess and autoconf and automake for almost all
> RedHat SRPMS ... and CentOS doesn't change those, unless absolutely
> necessary.
Which is what I agree is most preferrable.
> Therefore, for almost all packages on CentOS-3 they are --march=i386
> --mtune=i686 ... 
Maybe I need to look a bit deeper then.  I could have swore I've seen
many packages with Makefiles (after any autoconf) that clearly send to
stdout a "gcc ... --march=i486".  Maybe I'm thinking too much of
just
the kernel itself.
> and for most CentOS-4 packages they are --march=i386 --
> mtune=pentium4 ... being that the default target is i386.
Yep, I guess the --mtune=pentium4 was introduced with FC2+.
I would recommend Intel backtrack though, because it's not the
most ideal for other i686 architectures (only true P4 or Athlon).
Although the performance hit is not that much.


--
Bryan J. Smith   mailto:b.j.smith at ieee.org