Discuss

discuss@lists.centos.org

5 participants
34752 discussions

script to make a CentOS 4.0 respository updates server...
by israel.garcia＠cimex.com.cu 21 Jun '05

21 Jun '05

List, I have a CentOS 4.0 server in my intranet which will serves as a CentOS repository updates, so I need a script to do that job, I can not use RSYNC. I just want to download CentOS 4.0 updates every night. Can you help me? Regards, Israel

3 2

3.x ->3.5 update?
by Les Mikesell 20 Jun '05

20 Jun '05

On my Centos 3.4 boxes that were up to date a day or two ago, yum wants to update just about everything today. Is that normal? -- Les Mikesell lesmikesell(a)gmail.com

3 5

Re: [CentOS] CentOS 4.0 -> 4.1 update failing
by Bryan J. Smith <b.j.smith＠ieee.org> 20 Jun '05

20 Jun '05

From: Matthew Miller <mattdm(a)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@ieee.org

1 0

PenDrive still don't mount
by Dominik Składanowski 20 Jun '05

20 Jun '05

Hi. Few days ago I wrote about this problem (http://lists.centos.org/pipermail/centos/2005-June/007086.html) Now, after upgrade I have CentOS 4.1 and problem still exist. Regards. -- ____________________________________________________________________ D o m i n i k S k ł a d a n o w s k i

3 8

acpi_power_off called
by Fatih Ölçer 20 Jun '05

20 Jun '05

i cannot shutdown the computer. i get "acpi_power_off called" message. thanks.

3 2

Re: [CentOS] CentOS 4.0 -> 4.1 update failing
by Bryan J. Smith <b.j.smith＠ieee.org> 20 Jun '05

20 Jun '05

From: Johnny Hughes <mailing-lists(a)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@ieee.org

2 1

laptop screen saver failing
by Jerry Geis 20 Jun '05

20 Jun '05

My dell 8200 has centos 4.1 installed. Everything works great except the X screen saver. when it kicks in my screen goes WHITE and not what ever the selection is for the screen saver (star field, blank screen, etc..) When I do Applications, preferences, screen saver it says "The XScreenSaver daemon doesnt seem to be running on display 0:0? Launch it now?" Cancel/ Ok After that it works. What is not set correctly. Thanks, Jerry

1 0

4.1 x86_64 doesn't contain a mkbootdisk rpm
by Ceg Ryan 20 Jun '05

20 Jun '05

4.1 x86_64 doesn't contain a mkbootdisk rpm Then, How do I make a bootdisk easily ? (I know how to use grub to make the bootdisk.) But any other easier method ? Thx !

3 3

is there a 3.5 dvd torrent
by Robin Mordasiewicz 20 Jun '05

20 Jun '05

I cannot seem to find the 3.5 dvd torrent. Does anyone know where this is. --

5 5

Re: i486 and i686 are the majority ISAs for x86 -- WAS: CentOS 4.0 -> 4.1 update failing
by Bryan J. Smith <b.j.smith＠ieee.org> 20 Jun '05

20 Jun '05

From: alex(a)milivojevic.org > At various points in time Red Hat made some somewhat conflicting > decisions. The first was that Red Hat distributions must have NPTL. > For NPTL support, there are two components of system where it is > implemented, kernel and glibc. Back then glibc supported NPTL only > for i686. NPTL support was later backported to i586 and i486. Also remember that sometimes someone has to adopt something before the issues are well known and accommodated. More often than not, this is Red Hat. > Kernel should be fine with i486 and newer. There will never be > i386 support for NPTL, since i386 lacks some assembly instructions > needed to implement it effectively (NPTL i386 system would be > unusably slow). Exactly. Today, I don't expect Linux to run on anything but an i486 ISA or higher. The TLB and other augmentations of the i386 ISA are huge upswings in performance. I'm not talking about Intel- specific product additions (cache, FPU, etc...), but the actual ISA an features like the TLB. Pretty much everyone since the mid-'90s has been producing a i486 compatible ISA, including pretty much every embedded product. The i586 is _only_ for _genuine_ Pentium/Pentium MMX. It should _never_ be used on anything else -- and that includes the Pentium Pro on-ward, which are i686 ISA. The i686 ISA and designs fix a massive amount of serious design errors made in both the Pentium ALU itself as well as considerations in its i586 ISA. To be fair to Intel, it was their first superscalar design. But at the same time, NexGen was able to pull off an even better, superscalar ALU, and much of Intel's "design assistance" came indirectly from joining Digital on the Alpha chip briefly. i486 ISA Compatible Architectures - AMD: 486, 586, K5 (both original and Nx586+FPU), SCLan - Cyrix: 5x86, 6x86, M1 - IDT/Centaur: WinChip (just the original?) - SGS-Thompson: Nearly all cores (except very latest) i686 ISA Compatible Architectures - AMD: K6, Athlon, Athlon64/Opteron - Cyrix/NS: M2, Geode - IDT/Centaur: WinChip2+ (or WinChip4+?) - SGS-Thompson: Latest cores are i686? - ViA: C3 The only major processor I know that was only i386 ISA compatible, but had Pentium-like features (as well as its own idea of a TLB) was the original NexGen Nx586. AFAIK, the rev of the Nx586 with a non-pipelined FPU was fully i486 ISA comaptible, and became AMD's K5 design at higher ratings (120+?). Either that, or it was AMD's changes for the K5 that made it i486 compatible (and the K6 was a rev to make it fully i686 compatible). i486 cores were still popular until very recently. National Semi has been liberal in its licensing of the M2/Geode cores, which are i686 ISA compatible. I believe SGS-Thompson how has their own core offering that is i686. Almost everything else out there is based on these two -- and even AMD has gone Geode and deprecated its SCLan for embedded PC duties. > Then, Red Hat dropped i386 kernels, and continued to support i586 > and i686 kernels only. However on the glibc side, i386 and i686 > builds were used. This broke things badly in Fedora Core 2 for i586 > machines for some packages that used Berkely DB library (most > notably, Cyrus IMAPD was the most problematic package). I'm sure Red Hat's rationale was that the fact that i586 architectures are _very_rare_ now -- the original Pentium and Pentium MMX _only_. Using i586 ISA (especially i586 optimizations) on i686 is _detrimental_ to performance -- even Intel's own. I know most people don't know this, but it's a very well known fact among developers. > Now, I'm not sure if this part is urban legend or reality. Apperently they > "fixed" it in Fedora Core 3. The fix was not i586 version of glibc (which > would be logical, glibc is one of the few rare packages that might actually > benefit from i586 instruction set, But _only_ on _true_ Pentium and Pentium MMX. On a K6, M2, Pentum Pro and latter revisions, you want to use i686, _not_ i586. Trust me on this, there are a lot of "hacks" to i586 code because of the massive bugs in its superscalar ALU. One of the reasons for MMX was actually to introduce instructions to work around the design flaws (hence why 45 of the 47 instructs of MMX are integer related -- sometimes using the single FPU pipe instead of the dual-ALU pipe for operations that should normally be done by the ALU). > if nothing else than because of mandatory NPTL support for Red Hat > distributions). What they did was to build i386 version of glibc with > NPTL part using i486 instructions (at that point in time, glibc folks > have already backported NPTL to i486 and i586). I would personally wish Red Hat, and the rest of the Linux community, would just call the packages "i486" when you need an i486 ISA. But I'm sure that would break a lot of package managers. But I would have still done it as of either Red Hat Linux 8.0 or Fedora Core 2. Red Hat has essentially been building i486 ISA with i686 optimizations (but not i686 ISA) as standard years ago (RHL8? 7.3?). I know they flirted (adopted?) P4 optimizations since Athlon seems to do well with them too. > Now, *if* i586 is supported architecture for distribution (are they > shipping i586 kernel? what release notes for distro say?), then this > should be considered as a bug. Red Hat _avoided_ ever shipping an i586 ISA distro, let alone I do _not_ think they _ever_ optimized for i586 -- other than a few release kernels. i586 is _only_ good for Pentium / Pentium MMX from a performance standpoint. > What might be checked first is if FC3 NPTL fix for i386 glibc is reallity? > Is it included with RHEL4 glibc? It would surprise me if anyone put in the effort to build a release- quality set of NPTL patches for i386. i486 or higher has really been the realm of even the embedded x86 core since the mid-'90s, and the i686 since the turn of the millenium. Hence why it's really not worth Red Hat's bother to ship anything but i686 ISA, because people who subscribe to RHEL are typically running mid-to-late '90s hardware on-ward. I would almost argue they should adopt the same attitude for Fedora Core, although SPEC files in FC should _always_ be capable of building at least i486. Supporting the i386 at this point is just not worth it. Even Alan Cox pointed this out to me when I questioned the move to i486 years ago, that even embedded x86 cores have been i486 for a long, long time and the "drop" in performance due to lacking instructions for addressing, TLB, etc... in the i386 ISA just make it a poor solution in general. From: alex(a)milivojevic.org > %ifarch %{nptlarches} > %define enablekernelnptl 2.4.20 > %ifarch i386 > %define nptl_target_cpu i486 > %define tls_subdir tls/i486 > %else > %define nptl_target_cpu %{_target_cpu} > %define tls_subdir tls > %endif > %endif > So, I'd say just compile it for i386, and it should work correctly. It'll use > i486 instructions for NPTL support. Some testing to see if NPTL is really > working might be needed. That's apperently the way Red Hat is doing it, so > CentOS should follow. If you watch the build of nearly all packages -- especially the kernel and GLibC -- when targetting the i386, you'll see "--march=486" which is _clearly_ requiring a i486 ISA. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss