Discuss July 2005

discuss@lists.centos.org

190 participants
231 discussions

Compaq cpqfc driver
by bertchen＠biomaps.rutgers.edu 01 Jul '05

01 Jul '05

Hi, I am trying to compile kernel 2.6.9-11.EL from kernel-sourcecode, and need the Compaq cpqfc HBA driver. I see the code for the driver under drivers/scsi but when I do a "make menuconfig" I do not have the option to select it. Any ideas on how I can get it to show up? Thanks. --

2 1

RPM -e for single architecture
by David Thompson 01 Jul '05

01 Jul '05

Hi All: On architectures where multiple architectures for an RPM may be simultaneously installed (my example is x86_64), does anyone know the RPM magic to remove only one version? For instance, if I have the x86_64 and i386 versions of an RPM installed, how I can specify to only remove the i386 version? I have been unable to find a search phrase that turns up any useful information. Thanks. Dave Thompson UW-Madison (ftp|http|rsync)://mirror.cs.wisc.edu/pub/mirrors/linux/centos

3 2

Postfix / Postini question
by Barry Brimer 01 Jul '05

01 Jul '05

I have a mail server that handles several domains. One of these domains has decided to use Postini. For those not familiar with Postini, you set your MX records to use their mail servers. They filter mail, and deliver you only the clean virus/spam free mail. The idea is to only allow incoming mail from their mail servers so spammers are unable to send to your mail server directly. This is fairly simple to do with standard restriction classes for a dedicated mail server. I am not sure how to accomplish this on a shared mail server. Ideally I would like to instruct postfix to accept mail from anywhere for all domains except one domain (the one using Postini) and only allow mail destined for that specific domain to originate from Postini's mail servers. Any ideas would be greatly appreciated. Thanks, Barry

2 8

Mark Mulconry/SYR/Empire is out of the office.
by Mark.Mulconry＠empireblue.com 01 Jul '05

01 Jul '05

I will be out of the office starting 06/30/2005 and will not return until 07/06/2005. Please call Ken Milberg at 718-312-5070 or Steve Goldman at 718-312-5075 if you have a midrange issue. Otherwise, I will respond to your note upon my return. "WellChoice, Inc." made the following annotations on 07/01/05 08:03:17 ------------------------------------------------------------------------------ Attention! This electronic message contains information that may be legally confidential and/or privileged. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Release/Disclosure Statement

1 0

MPlayer problem
by Dominik Składanowski 01 Jul '05

01 Jul '05

Hi, I have installed MPlayer from dag repo on my CentOS 4.1 and codecs from MPlayer site. When I try to watch some movie file I get an error: ----------------------------------------------------------------------- Error opening/initializing the selected video_out (-vo) device. ----------------------------------------------------------------------- When I start MPlayer from console (gmplayer movie.mpeg &), there is: ----------------------------------------------------------------------- [dominik@localhost]$ gmplayer movie.mpeg & [1] 4102 [dominik@localhost]$ Using GNU internationalization Original domain: messages Original dirname: /usr/share/locale Current domain: mplayer Current dirname: /usr/share/locale MPlayer 1.0pre7-3.4.3 (C) 2000-2005 MPlayer Team CPU: Intel (Family: 6, Stepping: 6) Detected cache-line size is 64 bytes CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 vo: X11 running at 1024x768 with depth 24 and 32 bpp (":0.0" => local display) Linux RTC init error in ioctl (rtc_irqp_set 1024): Permission denied Try adding "echo 1024 > /proc/sys/dev/rtc/max-user-freq" to your system startup scripts. Opening joystick device /dev/input/js0 Can't open joystick device /dev/input/js0 : No such file or directory Can't init input joystick Setting up LIRC support... mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Profile size field missing from iCCP chunk ----------------------------------------------------------------------- Regards. -- ____________________________________________________________________ D o m i n i k S k ł a d a n o w s k i e-mail: dominik.skladanowski(a)ch.pw.edu.pl

2 2

CentOS newbie question - updates
by Chris (CentOS list) 01 Jul '05

01 Jul '05

Pardon the newbie question, but I thought I'd check with you guys here since I couldn't find the answer to this one on CentOS web site. I installed CentOS 3.4 (needed an equivalent of RHEL 3.4 for a very specific purpose - not interested in newer releases at this point) and downloaded all available up2date stuff. However, Apache is at v2.0.46, php is at 4.3.4, and so on - which are all quite old versions. I was under the impression that Red Hat rolls updates into existing versions and what may show as Apache 2.0.46, may indeed include updates and patches that are available in the most current release, 2.0.54..... Is this the case here, with CentOS, or should I be looking somewhere for actual rpms for Apache, php, and so on, to bring them up to 'latest' standards? If so - where?? up2date doesn't seem to be loading anything more current than what I mentioned above. If current patches are rolled into old versions, how does one distinguish between the "old" Apache 2.0.46 and "new/patched" 2.0.46?? Thanks, Chris

3 3

RE: [CentOS] [OT] SPARC platforms -- WAS: Hot swap CPU
by Bryan J. Smith <b.j.smith＠ieee.org> 01 Jul '05

01 Jul '05

From: Peter Arremann <loony(a)loonybin.org> > Sun will very willingly support all certified solutions (including EMC, netApp > or Hitachi for storage) as well as provide some support with uncertified > hardware for us... no issues... You work in a Fortune 5, they will do anything you tell them. I've been there before, and that is a very nice position to hold. But not when you work for a 50 engineer semiconductor startup. Sun really pissed us off regularly, so we stuck with Fujistu. > Yep - but how is that a benefit if your stuff works? NVidia is fabless i.e. > and you surely don't want to tell me they aren't good at what they do... > Having your own fab or not has very little influence... I was just saying that anyone who only wants to go to Sun because they are behind SPARC might consider Fujitsu, who actually fabs the chips. I've walked into many shops who have had issues with Sun's support and they never knew about Fujitsu as an option. That's all. > Sbus ???? Now you're talking US-I/II again - and that is absolutely > no match for an opteron box... Sorry, I meant NUMA/UPA -- my bad. > Based on what? The Implementation of Solaris for AMD dates back to SE b68 or > 69... that's mid 2004... Compare that to an OS that already ran on the > software emulator before silicon was even out there... Solaris was _also_ running on the x86-64 emulator too. ;-> AMD and Sun were in negotiations before the first Opteron came out. > Solaris 10 on AMD64 is definitely less stable that Centos 4 on the same v40z... > Running the same apps we had 0 crashes with Linux vs. 2 explained and > patched, 1 explained still unpatched and 1 unexplained crash on Solaris10... I meant the design: "given its experience on partial mesh interconnected systems" I thought by putting that in the _same_statement_ you'd see what I meant by "mature." Sorry, I assumed wrong. ;-> > Why would you need to run on sparc to produce a stable OS for an opteron box? Re-read my full statement ... 'Solaris is probably the most "mature" OS for Opteron 200/800 right now, given its experience on partial mesh interconnected systems.' -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

Good, concurrent I/O design in a server -- WAS: SPARC platforms
by Bryan J. Smith <b.j.smith＠ieee.org> 01 Jul '05

01 Jul '05

From: Peter Arremann <loony(a)loonybin.org> > When have I ever argued about that chipset design is better? :-) > Opteron is a great example that you can do it better... > Where did you even get the idea I am fixated on that??? http://lists.centos.org/pipermail/centos/2005-June/007341.html "<even more anal>Except the iommu, those are limitations of chipset, bus and whatever, not EM64T.</even more anal>" It very much has to do with how EM64T differs from AMD64. GARTs and I/O MMUs are even more capable than the Opteron. The issue has not yet been forced on Intel _because_ they still use a "single point of contention" design. All CPUs share one bus, all memory shares another, etc... into a "hub" (with exception of a proprietary NUMA solution, but all I/O still goes through that MCH "hub" on even those designs). http://lists.centos.org/pipermail/centos/2005-June/007662.html "Lets be realistic here... all I/O on one CPU only makes a difference for the most IO intensive apps (talking several hundret MB/sec or more)..." avoid boards that attach all memory to one cpu - unless they cost .. so much less that you can add another gig or two in memory... I/O on the other hand, while not ideal, will have much lesser effect on your performance." This is very much an issue. If I have an OS that has processor affinity for I/O, like Solaris, on a partial mesh platform like most SPARCs (non-"i" versions), or the newer Opteron (with multiple AMD8131/8132 or even the nVidia Pro 2200+2050 combo), then I'm going to be able to handle _concurrent_ I/O for independent (and sometimes even inter-dependent) processors. You think of "raw throughput" like 8.4GBps FSB can easily handle a 0.5GBps transfer, but what you don't realize that the 0.5GBps transfer holds up the _entire_ 8.4GBps bus for _just_ 0.5GBps. I.e., it takes 1 second for a 0.5GBps burst from the I/O, which means you do _not_ "get the other 7.9GBps" while it's tied up. Now on workstations, not too much of an issue (except for when you need all: video, NIC, storage). And maybe not a web server where your Internet pipe is only 100Mbps. But if you are a major communications carrier, or even just a heavily trumped file server, near-line server (with both in-band and out-of-band connects), possibly multiple DB, etc..., it really _does_ make a _lot_ of different. http://lists.centos.org/pipermail/centos/2005-June/007668.html "The board: Asus K8N-DL" A board recommendation you ahd to quickly backtracked on after a post by myself. You even said: http://lists.centos.org/pipermail/centos/2005-June/007674.html "But give me some credit - after all it was you who threw out the $300 price mark and besides that, the original poster said he had no real IO requirements ... Completely agreed - spend the extra money if you want to build a serious server... " Which made me scratch my head, because there were other $300 boards with 8-16x the PCI I/O capability because they had an AMD8131. And that's just to start. Which is what these threads are all about, how to build high performance servers, which may not be the same as for yourself. The hot-plug thread, that's just the total icing on the cake because you can't possibly see why someone might want an old NUMA/SBUS platform. You can assume I'm "wrong," or go out-of-your-way to talk about it. But that's _not_ while I'm posting. I'm posting so people are aware that there _are_ applications where you _might_ want such capabilities. Your continued insistence in asserting there is no application whatsoever is what *I* have a "problem" with. It's not about "wrong" -- it's about what people _might_ need. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: Hot swap CPU -- "build" is not a good CPU benchmark
by Bryan J. Smith <b.j.smith＠ieee.org> 01 Jul '05

01 Jul '05

From: Peter Arremann <loony(a)loonybin.org> > It is a valid benchmark though :-) compile speed is a actually a > good measure for any integer app that is small enough to run in > large cache... Image processing, oil companies for their simulations, > cad... they all act very similar to compile benchmark - if a compile > is twice as fast, a software image rendering is usually twice as fast > too :-) Now hold on. Did I just here you state that the ALU is used for CAD, and most scientific and engineering applications? Now I'll grant you that _some_ image processing _can_ be 32/64-bit integer transforms. But most high-quality, 64-bit precise transforms use the FPU. Not even Intel's SSE (on the P3/P4) is good when you need such precision. In fact, I don't know how many times I've caught errors because someone threw the "-O3" switch on "-march=p4". You do _not_ want to use SSE for scientific computing -- it's for when you want performance in exchange for loss of precision (let alone accuracy). > If you run databases or so, then yes, your comment is valid. Thank you. > Fair enough :-) And people say *I* go off on tangents. No offense, you were already in 2 posts before I even responded. If you look at other threads, I'm typically responding "OT" after 2-3 people have done so, and I largely see an inaccuracy, or I see a correction very much necessary. [ My posts on that thread _prior_ had just been to inform people that yes, there _were_ Xeon and Itanium systems with hot-swap capability. ] That's all I was trying to do in this case. Not "prove you wrong." -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

RE: [CentOS] [OT] SPARC platforms -- WAS: Hot swap CPU
by Bryan J. Smith <b.j.smith＠ieee.org> 01 Jul '05

01 Jul '05

From: Peter Arremann <loony(a)loonybin.org> > US-V has been canceled... By Sun, yes. They believe they will transition to Opteron sooner than they thought. All I said was that it had been "planned through" US-V, including the design work done. My bet is that the engineers had finished the core design, even if not fully optimized, and that's when they were canned. It's still an option in the back of Sun's pocket. [ I.e., the core design occurs _years_ before products become available. E.g., even the latest Opterons are based on the 1997 core design. And until the Pentium 4 came out (just a refit), the Pentium 3 was still based on the 1994 Pentium Pro core. ] Fujitsu has yet to weigh in and possibly pick up the design. They have been designing SPARC modules (better ones IMHO) for a long time. All it takes is 1 customer who needs SPARC binary compatibility. There was an equal battle over the Alpha 364, with OpenVMS the driver. Especially since OpenVMS/Itanium was _slower_ (than an Alpha 264 from 3 years earlier no less!). But once [quality] emulators became available, that killed it. I don't think you'll see the same with SPARC, but I could be wrong. If the need by just 1 major user is there, you can be sure Fujitsu will come out with a PRIMEPower upgrade that uses the design. I never said Sun would release an UltraSPARC V, I just said it has been planned (i.e., designed). Sun has made it known that as of right now, UltraSPARC IV is the "end-of-the-line" for Solaris, and given how Solaris is working on Opteron, I don't blame them. But HP is _still_ selling Alpha 264s because of OpenVMS. ;-> A platform they have tried to kill off again and again and again. > US-IIIi is up to 4 way... I _never_ said it wasn't. I just said the 1-2 ways are comparable to a typical PC design**. But after 2-way, it's much better to go with a US-III or US-IV, kinda like it's much better to go with an Opteron instead of a Xeon beyond 2-way**. ;-> -- Bryan **NOTE: This is a recurring theme. You seem fixated on the assumption that a system that uses a single-point-of-contention design (namely the Intel MCH aka "northbridge") approach would _always_ be faster. You seem to lack the understanding beyond the real design contraints of a partial mesh interconnect on a real system interconnect (and not just a peripheral interconnect hacked on as a system interconnect). You have degraded most of my commentary as a "that's a chipset issue." You seem to have a very limited understanding outside of the traditional PC CPU-to-memory or CPU-to-I/O via a "chipset" and that's why you keeping missing my points on Opteron, UltraSPARC, etc... Not to mention this thread was just about finding a solution with hot-swappable components. I left it at that _until_ you wanted to assert all sorts of things (using "builds" as a benchmark for servers, even computational ones). -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

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 July 2005