From peacmen at nexaweb.com Sat Oct 2 16:45:35 2004 From: peacmen at nexaweb.com (Peter Eacmen) Date: Sat, 2 Oct 2004 12:45:35 -0400 Subject: Help - Need a driver built against FC2 x86_64 Message-ID: I want to install FC2 on my amd64 system. But I have a RAID 0 array setup with a Promise 378 (the Asus A8V integrated controller). When I start the FC2 install each drive is displayed seperatly. Promise has released the source for the linux driver, but noone has built it against the x86_64 FC2 kernel (not that I can find anyway). Can someone please build this for me against the default x86_64 kernel config for FC2? The driver zip is attached, or you can download it at http://www.promise.com/support/file/driver/1_fasttrak_tx4000_partial_source_ 1.00.0.19.zip Does anyone know how to find out what drivers are slated to be included in FC3? Thanks! -peter -------------- next part -------------- A non-text attachment was scrubbed... Name: 1_fasttrak_tx4000_partial_source_1.00.0.19.zip Type: application/x-zip-compressed Size: 131690 bytes Desc: not available URL: From dwaquilina at gmail.com Sat Oct 2 17:27:54 2004 From: dwaquilina at gmail.com (David Aquilina) Date: Sat, 2 Oct 2004 13:27:54 -0400 Subject: Help - Need a driver built against FC2 x86_64 In-Reply-To: References: Message-ID: On Sat, 2 Oct 2004 12:45:35 -0400, Peter Eacmen wrote: > Does anyone know how to find out what drivers are slated to be included in > FC3? Short of installing one of the test releases and taking a look, if you download just the kernel RPM and do: rpm -q --filesbypkg -p kernel-2.6.whatever.rpm | less It should give you a pretty good idea of what's there. -- David Aquilina, RHCE dwaquilina at gmail.com From arjanv at redhat.com Sat Oct 2 18:22:06 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 02 Oct 2004 20:22:06 +0200 Subject: Help - Need a driver built against FC2 x86_64 In-Reply-To: References: Message-ID: <1096741326.2900.0.camel@laptop.fenrus.com> On Sat, 2004-10-02 at 18:45, Peter Eacmen wrote: > I want to install FC2 on my amd64 system. But I have a RAID 0 array setup > with a Promise 378 (the Asus A8V integrated controller). When I start the > FC2 install each drive is displayed seperatly. > > Promise has released the source for the linux driver, but noone has built it > against the x86_64 FC2 kernel (not that I can find anyway). Can someone > please build this for me against the default x86_64 kernel config for FC2? > > The driver zip is attached, or you can download it at > http://www.promise.com/support/file/driver/1_fasttrak_tx4000_partial_source_ > 1.00.0.19.zip this is not an open source driver. It's a binary driver with a glue layer. However what you need is probably solved with the dmraid tool we're developing.... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From manolo at miconexion.com Sat Oct 9 10:37:55 2004 From: manolo at miconexion.com (Manuel Moreno) Date: Sat, 09 Oct 2004 11:37:55 +0100 Subject: kernel-2.6.8-1.603 problem with reboot Message-ID: <1097318275.4312.5.camel@mgmk7.mgmux.com> Without this patch reboot() panics on find_isa_irq_pin (x86_84) It is maybe needed on 'i386' too? Rgds. -- Manuel Moreno -------------- next part -------------- A non-text attachment was scrubbed... Name: linux-2.6.9-find__isa_irq_pin_no_init.patch Type: text/x-patch Size: 728 bytes Desc: not available URL: From manolo at miconexion.com Sat Oct 9 10:43:34 2004 From: manolo at miconexion.com (Manuel Moreno) Date: Sat, 09 Oct 2004 11:43:34 +0100 Subject: problem with evolution2 and contacts... Message-ID: <1097318614.4312.9.camel@mgmk7.mgmux.com> evolution-2.0.1-2 on x86_64 when trying to open contacts ********** Error loading addressbook. We were unable to open this addressbook. Please check that the path exists and that you have permission to access it ********** It works ok on i386, though. -- Manuel Moreno From fds at sdsc.edu Thu Oct 14 20:58:57 2004 From: fds at sdsc.edu (Federico Sacerdoti) Date: Thu, 14 Oct 2004 13:58:57 -0700 Subject: Ping RTT clock resolution problem on x86_64 Message-ID: Hello, I am a developer from the Rocks project in San Diego. We are noticing a problem with the clock resolution for TCP round trip times that only emerges on AMD Opteron systems. The bug is characterized as follows: The issue is that the clock resolution is only 10ms: ie any rtt value between 0-10ms is reported as 0.00ms. --On Opteron (bug)-- root at www root]# ping google.com PING google.com (216.239.37.99) 56(84) bytes of data. 64 bytes from 216.239.37.99: icmp_seq=0 ttl=238 time=89.9 ms 64 bytes from 216.239.37.99: icmp_seq=1 ttl=238 time=79.9 ms 64 bytes from 216.239.37.99: icmp_seq=2 ttl=236 time=79.9 ms [root at www root]# ping nbc.com PING nbc.com (63.241.60.70) 56(84) bytes of data. 64 bytes from nbc.com (63.241.60.70): icmp_seq=0 ttl=53 time=0.000 ms 64 bytes from nbc.com (63.241.60.70): icmp_seq=1 ttl=53 time=0.000 ms --On Other systems (normal)-- [root at rocks-43 root]# ping google.com PING google.com (216.239.57.99) 56(84) bytes of data. 64 bytes from 216.239.57.99: icmp_seq=0 ttl=244 time=11.5 ms 64 bytes from 216.239.57.99: icmp_seq=1 ttl=244 time=11.8 ms 64 bytes from 216.239.57.99: icmp_seq=2 ttl=244 time=11.5 ms 64 bytes from 216.239.57.99: icmp_seq=3 ttl=244 time=11.7 ms [root at rocks-43 root]# ping nbc.com PING nbc.com (63.241.60.70) 56(84) bytes of data. 64 bytes from nbc.com (63.241.60.70): icmp_seq=0 ttl=53 time=7.41 ms 64 bytes from nbc.com (63.241.60.70): icmp_seq=1 ttl=53 time=7.32 ms 64 bytes from nbc.com (63.241.60.70): icmp_seq=2 ttl=53 time=7.39 ms 64 bytes from nbc.com (63.241.60.70): icmp_seq=3 ttl=53 time=7.33 ms This behavior happens for several different types of ethernet cards on opterons, and is not observed on either Pentium or Nocona systems. Has anyone noticed this before? Our kernel version is: (Nocona) Linux rocks-43.sdsc.edu 2.4.21-20.EL #1 SMP Fri Oct 1 09:12:23 PDT 2004 x86_64 x86_64 x86_64 GNU/Linux (Opteron) Linux www.rocksclusters.org 2.4.21-20.ELsmp #1 SMP Sat Sep 18 18:28:16 PDT 2004 x86_64 x86_64 x86_64 GNU/Linux Thank you, Federico Rocks Cluster Group, San Diego Supercomputer Center, CA From joshua at iwsp.com Fri Oct 22 14:27:03 2004 From: joshua at iwsp.com (Joshua Jensen) Date: Fri, 22 Oct 2004 10:27:03 -0400 Subject: Ping RTT clock resolution problem on x86_64 In-Reply-To: References: Message-ID: <20041022142703.GB17454@iwsp.com> Please say that you have entered this in bugzilla... this is important Joshua On Thu, Oct 14, 2004 at 01:58:57PM -0700, Federico Sacerdoti wrote: > Hello, > > I am a developer from the Rocks project in San Diego. We are noticing a > problem with the clock resolution for TCP round trip times that only > emerges on AMD Opteron systems. The bug is characterized as follows: > > The issue is that the clock resolution is only 10ms: ie any rtt value > between 0-10ms is reported as 0.00ms. > > --On Opteron (bug)-- > root at www root]# ping google.com > PING google.com (216.239.37.99) 56(84) bytes of data. > 64 bytes from 216.239.37.99: icmp_seq=0 ttl=238 time=89.9 ms > 64 bytes from 216.239.37.99: icmp_seq=1 ttl=238 time=79.9 ms > 64 bytes from 216.239.37.99: icmp_seq=2 ttl=236 time=79.9 ms > > [root at www root]# ping nbc.com > PING nbc.com (63.241.60.70) 56(84) bytes of data. > 64 bytes from nbc.com (63.241.60.70): icmp_seq=0 ttl=53 time=0.000 ms > 64 bytes from nbc.com (63.241.60.70): icmp_seq=1 ttl=53 time=0.000 ms > > > --On Other systems (normal)-- > [root at rocks-43 root]# ping google.com > PING google.com (216.239.57.99) 56(84) bytes of data. > 64 bytes from 216.239.57.99: icmp_seq=0 ttl=244 time=11.5 ms > 64 bytes from 216.239.57.99: icmp_seq=1 ttl=244 time=11.8 ms > 64 bytes from 216.239.57.99: icmp_seq=2 ttl=244 time=11.5 ms > 64 bytes from 216.239.57.99: icmp_seq=3 ttl=244 time=11.7 ms > > [root at rocks-43 root]# ping nbc.com > PING nbc.com (63.241.60.70) 56(84) bytes of data. > 64 bytes from nbc.com (63.241.60.70): icmp_seq=0 ttl=53 time=7.41 ms > 64 bytes from nbc.com (63.241.60.70): icmp_seq=1 ttl=53 time=7.32 ms > 64 bytes from nbc.com (63.241.60.70): icmp_seq=2 ttl=53 time=7.39 ms > 64 bytes from nbc.com (63.241.60.70): icmp_seq=3 ttl=53 time=7.33 ms > > > This behavior happens for several different types of ethernet cards on > opterons, and is not observed on either Pentium or Nocona systems. > > Has anyone noticed this before? Our kernel version is: > > (Nocona) > Linux rocks-43.sdsc.edu 2.4.21-20.EL #1 SMP Fri Oct 1 09:12:23 PDT 2004 > x86_64 x86_64 x86_64 GNU/Linux > > (Opteron) > Linux www.rocksclusters.org 2.4.21-20.ELsmp #1 SMP Sat Sep 18 18:28:16 > PDT 2004 x86_64 x86_64 x86_64 GNU/Linux > > Thank you, > Federico > > Rocks Cluster Group, San Diego Supercomputer Center, CA > > -- > amd64-list mailing list > amd64-list at redhat.com > https://www.redhat.com/mailman/listinfo/amd64-list -- Joshua Jensen joshua at iwsp.com "If God didn't want us to eat animals, why did he make them out of meat?" From fds at sdsc.edu Fri Oct 22 20:56:29 2004 From: fds at sdsc.edu (Federico Sacerdoti) Date: Fri, 22 Oct 2004 13:56:29 -0700 Subject: Ping RTT clock resolution problem on x86_64 In-Reply-To: <20041022142703.GB17454@iwsp.com> References: <20041022142703.GB17454@iwsp.com> Message-ID: Not yet, is it open to the public? We have some indication that the "tsc" kernel flag fixes some of the timer problems. -Federico On Oct 22, 2004, at 7:27 AM, Joshua Jensen wrote: > Please say that you have entered this in bugzilla... this is important > > Joshua > > > > On Thu, Oct 14, 2004 at 01:58:57PM -0700, Federico Sacerdoti wrote: >> Hello, >> >> I am a developer from the Rocks project in San Diego. We are noticing >> a >> problem with the clock resolution for TCP round trip times that only >> emerges on AMD Opteron systems. The bug is characterized as follows: >> >> The issue is that the clock resolution is only 10ms: ie any rtt value >> between 0-10ms is reported as 0.00ms. >> >> --On Opteron (bug)-- >> root at www root]# ping google.com >> PING google.com (216.239.37.99) 56(84) bytes of data. >> 64 bytes from 216.239.37.99: icmp_seq=0 ttl=238 time=89.9 ms >> 64 bytes from 216.239.37.99: icmp_seq=1 ttl=238 time=79.9 ms >> 64 bytes from 216.239.37.99: icmp_seq=2 ttl=236 time=79.9 ms >> >> [root at www root]# ping nbc.com >> PING nbc.com (63.241.60.70) 56(84) bytes of data. >> 64 bytes from nbc.com (63.241.60.70): icmp_seq=0 ttl=53 time=0.000 ms >> 64 bytes from nbc.com (63.241.60.70): icmp_seq=1 ttl=53 time=0.000 ms >> >> >> --On Other systems (normal)-- >> [root at rocks-43 root]# ping google.com >> PING google.com (216.239.57.99) 56(84) bytes of data. >> 64 bytes from 216.239.57.99: icmp_seq=0 ttl=244 time=11.5 ms >> 64 bytes from 216.239.57.99: icmp_seq=1 ttl=244 time=11.8 ms >> 64 bytes from 216.239.57.99: icmp_seq=2 ttl=244 time=11.5 ms >> 64 bytes from 216.239.57.99: icmp_seq=3 ttl=244 time=11.7 ms >> >> [root at rocks-43 root]# ping nbc.com >> PING nbc.com (63.241.60.70) 56(84) bytes of data. >> 64 bytes from nbc.com (63.241.60.70): icmp_seq=0 ttl=53 time=7.41 ms >> 64 bytes from nbc.com (63.241.60.70): icmp_seq=1 ttl=53 time=7.32 ms >> 64 bytes from nbc.com (63.241.60.70): icmp_seq=2 ttl=53 time=7.39 ms >> 64 bytes from nbc.com (63.241.60.70): icmp_seq=3 ttl=53 time=7.33 ms >> >> >> This behavior happens for several different types of ethernet cards on >> opterons, and is not observed on either Pentium or Nocona systems. >> >> Has anyone noticed this before? Our kernel version is: >> >> (Nocona) >> Linux rocks-43.sdsc.edu 2.4.21-20.EL #1 SMP Fri Oct 1 09:12:23 PDT >> 2004 >> x86_64 x86_64 x86_64 GNU/Linux >> >> (Opteron) >> Linux www.rocksclusters.org 2.4.21-20.ELsmp #1 SMP Sat Sep 18 18:28:16 >> PDT 2004 x86_64 x86_64 x86_64 GNU/Linux >> >> Thank you, >> Federico >> >> Rocks Cluster Group, San Diego Supercomputer Center, CA >> >> -- >> amd64-list mailing list >> amd64-list at redhat.com >> https://www.redhat.com/mailman/listinfo/amd64-list > > -- > Joshua Jensen > joshua at iwsp.com > "If God didn't want us to eat animals, why did he make them out of > meat?" > > -- > amd64-list mailing list > amd64-list at redhat.com > https://www.redhat.com/mailman/listinfo/amd64-list > Federico Rocks Cluster Group, San Diego Supercomputer Center, CA From joshua at iwsp.com Fri Oct 22 23:04:57 2004 From: joshua at iwsp.com (Joshua Jensen) Date: Fri, 22 Oct 2004 19:04:57 -0400 Subject: Ping RTT clock resolution problem on x86_64 In-Reply-To: References: <20041022142703.GB17454@iwsp.com> Message-ID: <20041022230457.GB13035@iwsp.com> Yes!! Bugzilla is very much a public thing. Please file it! On Fri, Oct 22, 2004 at 01:56:29PM -0700, Federico Sacerdoti wrote: > Not yet, is it open to the public? We have some indication that the > "tsc" kernel flag fixes some of the timer problems. > > -Federico > > On Oct 22, 2004, at 7:27 AM, Joshua Jensen wrote: > > >Please say that you have entered this in bugzilla... this is important > > > >Joshua > > > > > > > >On Thu, Oct 14, 2004 at 01:58:57PM -0700, Federico Sacerdoti wrote: > >>Hello, > >> > >>I am a developer from the Rocks project in San Diego. We are noticing > >>a > >>problem with the clock resolution for TCP round trip times that only > >>emerges on AMD Opteron systems. The bug is characterized as follows: > >> > >>The issue is that the clock resolution is only 10ms: ie any rtt value > >>between 0-10ms is reported as 0.00ms. > >> > >>--On Opteron (bug)-- > >>root at www root]# ping google.com > >>PING google.com (216.239.37.99) 56(84) bytes of data. > >>64 bytes from 216.239.37.99: icmp_seq=0 ttl=238 time=89.9 ms > >>64 bytes from 216.239.37.99: icmp_seq=1 ttl=238 time=79.9 ms > >>64 bytes from 216.239.37.99: icmp_seq=2 ttl=236 time=79.9 ms > >> > >>[root at www root]# ping nbc.com > >>PING nbc.com (63.241.60.70) 56(84) bytes of data. > >>64 bytes from nbc.com (63.241.60.70): icmp_seq=0 ttl=53 time=0.000 ms > >>64 bytes from nbc.com (63.241.60.70): icmp_seq=1 ttl=53 time=0.000 ms > >> > >> > >>--On Other systems (normal)-- > >>[root at rocks-43 root]# ping google.com > >>PING google.com (216.239.57.99) 56(84) bytes of data. > >>64 bytes from 216.239.57.99: icmp_seq=0 ttl=244 time=11.5 ms > >>64 bytes from 216.239.57.99: icmp_seq=1 ttl=244 time=11.8 ms > >>64 bytes from 216.239.57.99: icmp_seq=2 ttl=244 time=11.5 ms > >>64 bytes from 216.239.57.99: icmp_seq=3 ttl=244 time=11.7 ms > >> > >>[root at rocks-43 root]# ping nbc.com > >>PING nbc.com (63.241.60.70) 56(84) bytes of data. > >>64 bytes from nbc.com (63.241.60.70): icmp_seq=0 ttl=53 time=7.41 ms > >>64 bytes from nbc.com (63.241.60.70): icmp_seq=1 ttl=53 time=7.32 ms > >>64 bytes from nbc.com (63.241.60.70): icmp_seq=2 ttl=53 time=7.39 ms > >>64 bytes from nbc.com (63.241.60.70): icmp_seq=3 ttl=53 time=7.33 ms > >> > >> > >>This behavior happens for several different types of ethernet cards on > >>opterons, and is not observed on either Pentium or Nocona systems. > >> > >>Has anyone noticed this before? Our kernel version is: > >> > >>(Nocona) > >>Linux rocks-43.sdsc.edu 2.4.21-20.EL #1 SMP Fri Oct 1 09:12:23 PDT > >>2004 > >>x86_64 x86_64 x86_64 GNU/Linux > >> > >>(Opteron) > >>Linux www.rocksclusters.org 2.4.21-20.ELsmp #1 SMP Sat Sep 18 18:28:16 > >>PDT 2004 x86_64 x86_64 x86_64 GNU/Linux > >> > >>Thank you, > >>Federico > >> > >>Rocks Cluster Group, San Diego Supercomputer Center, CA > >> > >>-- > >>amd64-list mailing list > >>amd64-list at redhat.com > >>https://www.redhat.com/mailman/listinfo/amd64-list > > > >-- > >Joshua Jensen > >joshua at iwsp.com > >"If God didn't want us to eat animals, why did he make them out of > >meat?" > > > >-- > >amd64-list mailing list > >amd64-list at redhat.com > >https://www.redhat.com/mailman/listinfo/amd64-list > > > Federico > > Rocks Cluster Group, San Diego Supercomputer Center, CA -- Joshua Jensen joshua at iwsp.com "If God didn't want us to eat animals, why did he make them out of meat?" From joelf at fast.net Thu Oct 28 22:24:30 2004 From: joelf at fast.net (joel) Date: Thu, 28 Oct 2004 15:24:30 -0700 Subject: HP DL585 install Message-ID: <1099002270.5770.282.camel@joelf-ws.labs.corp.yahoo.com> I have a quick question for you all. I am trying to install AS on a DL585 quad proc opteron. I can't get the install to see the drives even with updated drivers from HP for cciss. Anyone have any issue's with this? I need to get a new set of cd's is what HP is telling me. I have version 3 as of right now but I have no idea what release it is. RPM kernel verion is 2.4.21. How do I konw what relseas I have of Version 3. Thanks ~joel From dwaquilina at gmail.com Fri Oct 29 01:40:07 2004 From: dwaquilina at gmail.com (David Aquilina) Date: Thu, 28 Oct 2004 21:40:07 -0400 Subject: HP DL585 install In-Reply-To: <1099002270.5770.282.camel@joelf-ws.labs.corp.yahoo.com> References: <1099002270.5770.282.camel@joelf-ws.labs.corp.yahoo.com> Message-ID: On Thu, 28 Oct 2004 15:24:30 -0700, joel wrote: > How do I konw what relseas I have of Version 3. Look on the second CD within /Redhat/RPMS at the kernel version. If it's 2.4.21-4.EL, it's ancient (the GA release). Go to RHN and download Update 3 ISOs. If it's 2.4.21-20.EL, that's the newest and there won't be newer disks for another couple months at least. -- David Aquilina, RHCE dwaquilina at gmail.com