From lamont at gurulabs.com Tue Aug 1 14:55:34 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Tue, 1 Aug 2006 08:55:34 -0600 Subject: 2.6.18 & 64-bit resources Message-ID: <200608010855.39282.lamont@gurulabs.com> Taking a look at [ http://lwn.net/Articles/187490/ ], I'm thinking that this is a good thing and it looks like the affected kernel functions shouldn't impact existing driver code. However, does anyone have an opinion they would like to share about the impact this (potential) change for 2.6.18 might have on 64-bit systems (not just AMD64)? -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cochranb at speakeasy.net Sun Aug 20 01:52:52 2006 From: cochranb at speakeasy.net (Robert L. Cochran) Date: Sat, 19 Aug 2006 21:52:52 -0400 Subject: AM2, X2, Opteron, or Opteron Socket F? Message-ID: <008801c6c3fb$59d27450$3101a8c0@rclap> I recently gave my trusty, rock solid Athlon 64 X2 4400+ system to my wife (long story there, but it had to be done.) That leaves me with my not-so-trusty laptop and a searing desire to build a new system. My problem is deciding on a processor and motherboard. At first, I liked Intel Core 2 Duo, but the motherboard selection doesn't seem great and it is very pricy. Then I looked at socket 939 procs...I love them...but they can't do DDR2 memory. I'm also confused by the advantages of Socket F, socket 940 (which I know allows DDR2 memory), and the advantages of Opterons over Athlon 64s or Athlon 64 X2. Or vice versa. I need to do some heavy, heavy database programming and website building in the next 2 years. I want quick ethernet controllers. I'll be working mainly on a Linux platform, Fedora Core or possibly Red Hat Enterprise Linux. What AMD processor and motherboard would work best for me? Should I focus on Opterons? One last note -- my old system has an Asrock DualSATA-939 motherboard running the 2.20 BIOS. I took out the old ATI 9700 All-In-Wonder (AGP) video card and put a BFG GeForce 7600 GT OC in the PCI Express slot. It works great and powers my wife's 24" flat panel monitor at 1920 X 1200 resolution. Thanks Bob Cochran From bill at cse.ucdavis.edu Sun Aug 20 02:52:22 2006 From: bill at cse.ucdavis.edu (Bill Broadley) Date: Sat, 19 Aug 2006 19:52:22 -0700 Subject: AM2, X2, Opteron, or Opteron Socket F? In-Reply-To: <008801c6c3fb$59d27450$3101a8c0@rclap> References: <008801c6c3fb$59d27450$3101a8c0@rclap> Message-ID: <20060820025222.GI1964@cse.ucdavis.edu> On Sat, Aug 19, 2006 at 09:52:52PM -0400, Robert L. Cochran wrote: > I recently gave my trusty, rock solid Athlon 64 X2 4400+ system to my wife > (long story there, but it had to be done.) That leaves me with my > not-so-trusty laptop and a searing desire to build a new system. > > My problem is deciding on a processor and motherboard. > > At first, I liked Intel Core 2 Duo, but the motherboard selection doesn't > seem great and it is very pricy. I'm in a similar situation, indeed the Intel Core Duo seems to be fairly expensive and less available then the AM2 systems. On the AM2 side there's quite a selection of reasonably priced motherboards. > I'm also confused by the advantages of Socket F, socket 940 (which I know > allows DDR2 memory), and the advantages of Opterons over Athlon 64s or > Athlon 64 X2. Or vice versa. Rev F opterons or AM2 amd64's both differ primarily in that: * They support DDR2 memory * They have hardware support for virtualization. > I need to do some heavy, heavy database programming and website building in > the next 2 years. I want quick ethernet controllers. I'll be working mainly > on a Linux platform, Fedora Core or possibly Red Hat Enterprise Linux. You didn't mention a budget, certainly a dual socket/dual memory bus machine will have substantially more CPU cycles and memory bandwidth available. If your database is disk limited the extra cycles won't help at all. > What AMD processor and motherboard would work best for me? Should I focus > on Opterons? Opterons are more conservative, they receive more testing, although they share almost 100% of the transistors with the amd64's. For instance the am2 chips support DDR2-800 MHz, while the opterons support ddr2-667. Although that maybe more than DDR2-800 ECC registered dimms are hard to find. ECC memory is easier to get on the opteron, and opteron supporting motherboards are the rule, not the exception. The line is rather blurry though. For instance some motherboards accept amd64's and opteron 1xx's. I'm not sure if amd is going to do an opteron 1xx rev f, they didn't announce them and their pricing with the rest of the rev f's. > One last note -- my old system has an Asrock DualSATA-939 motherboard > running the 2.20 BIOS. I took out the old ATI 9700 All-In-Wonder (AGP) > video card and put a BFG GeForce 7600 GT OC in the PCI Express slot. It > works great and powers my wife's 24" flat panel monitor at 1920 X 1200 > resolution. I'm very happy with the 6600GT and 7600GT's I've used, they take significantly less power than the higher end cards while still delivering pretty good 2d/3d performance. Often the AGP versions require an extra power (to run the bridge chip) but usually the PCI-e versions do not. There's no real wrong choices to be made, personally I'm likely to get a x2 around 2.2 GHz. Cheap, fast, dual core, good enough for me. The intel core 2's to give you more performance per MHz in most cases, but the motherboards tend to be cost more, as does the CPU. Be careful about the DDR-2 memory you buy with a intel core 2. I've seen benchmarks that indicate that matching the FSB and the memory speed is faster than buying faster ram. I.e. if you get a 1066 MHz FSB get ddr2-533 (not 667 or 800), if you get a 1333 MHz FSB get DDR2-667 (not 533 or 800). -- Bill Broadley Computational Science and Engineering UC Davis From b.j.smith at ieee.org Sun Aug 20 18:53:11 2006 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Sun, 20 Aug 2006 14:53:11 -0400 Subject: AM2, X2, Opteron, or Opteron Socket F? In-Reply-To: <008801c6c3fb$59d27450$3101a8c0@rclap> References: <008801c6c3fb$59d27450$3101a8c0@rclap> Message-ID: <1156099991.2989.55.camel@bert64.oviedo.smithconcepts.com> On Sat, 2006-08-19 at 21:52 -0400, Robert L. Cochran wrote: > At first, I liked Intel Core 2 Duo, but the motherboard selection doesn't > seem great and it is very pricy. The price is worth it in computing power. Core is the first, _full_ Intel x86 redesign since the Pentium Pro. The NetBurst (P4) was a quick refit of extending the pipes and doing virtually _no_ refactoring in the ALU/FPU design (long story). I still don't recommend Core 2 Duo or even Intel's forthcoming dual-FSB processor for more than 2GiB on a server. Some may differ with me, but offsetting the limitations with lots of L2/L3 cache doesn't go far enough. They need a true interconnect and I/O MMU's on-processor. > Then I looked at socket 939 procs...I love them...but they can't do DDR2 > memory. Huh? Socket-AM2 (new 940) is just the Socket-939 with DDR2. What's DDR2 do for you? Not much. The reason why AMD switched to DDR2 had more to do with consumer as well as integrator/OEM memory cost. E.g., I'm sure Dell balked at the idea of going AMD when it had to keep separate memory options. > I'm also confused by the advantages of Socket F, Socket-F (LGA-1207) puts the pins on the mainboard instead of the CPU, since the Socket-F processors often cost more than the mainboard. There are other electrical advantages as well. AMD merely decided to introduce an LGA option for Opteron when it went DDR2. > socket 940 (which I know allows DDR2 memory), Do _not_ confuse "old" 940 Opteron with "new" 940 (AM2) Athlon 64. DDR: 754, 939, old-940 DDR2: new-940 (AM2), 1207 (F) > and the advantages of Opterons over Athlon 64s or Athlon 64 X2. > Or vice versa. It's now 2 years old, but here is my figure for interconnect and associated table of aggregate front-side throughput: http://www.samag.com/documents/sam0411b/0411b_f4.htm http://www.samag.com/documents/sam0411b/0411b_t1.htm The DDR2 options don't really do much as far as performance, although memory throughput does increase. There are also now only 1.0GHz HyperTransport but even 1.4GHz HyperTransport 2.0 options now in the LGA-1207 (Socket-F). Opteron definitely tests to better tolerances than Athlon 64, and is multiprocessor. > I need to do some heavy, heavy database programming and website building in > the next 2 years. I want quick ethernet controllers. Then buy quality Ethernet controllers, especially ones with RX (not just TX) TCP Off-load Engines (TOE) that have full Linux support. I've been playing with LeWiz Communications solutions -- because they have broad platform support. Their low-profile PCIe x8 4xGbE starts at under $1,000. I didn't know about them until LinuxWorld Boston (back in April): Server Hardware at Linux World: http://thebs413.blogspot.com/2006/04/server-hardware-at-linuxworld.html > I'll be working mainly > on a Linux platform, Fedora Core or possibly Red Hat Enterprise Linux. > What AMD processor and motherboard would work best for me? Should I focus on > Opterons? For servers, they might be worth a few extra bucks in full ECC support. They are required for multiple sockets -- especially when I/O is more important than computational. > One last note -- my old system has an Asrock DualSATA-939 motherboard > running the 2.20 BIOS. I took out the old ATI 9700 All-In-Wonder (AGP) video > card and put a BFG GeForce 7600 GT OC in the PCI Express slot. It works > great and powers my wife's 24" flat panel monitor at 1920 X 1200 resolution. The 7600GT is a great buy right now. If you want a high-performance, passively cooled video, the 7600GS is also nice and can be had for $90. It's great for set-top boxes because of its built-in HDTV output and video decoding support in MPlayer. -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith at ieee.org http://thebs413.blogspot.com --------------------------------------------------------- The world is in need of solutions. Unfortunately, people seem to be more interested in blindly aligning themselves with one of only two viewponts -- an "us v. them" debate that has nothing to do with finding an actual solution. From arjan at fenrus.demon.nl Sun Aug 20 20:08:42 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sun, 20 Aug 2006 22:08:42 +0200 Subject: AM2, X2, Opteron, or Opteron Socket F? In-Reply-To: <1156099991.2989.55.camel@bert64.oviedo.smithconcepts.com> References: <008801c6c3fb$59d27450$3101a8c0@rclap> <1156099991.2989.55.camel@bert64.oviedo.smithconcepts.com> Message-ID: <1156104522.23756.63.camel@laptopd505.fenrus.org> On Sun, 2006-08-20 at 14:53 -0400, Bryan J. Smith wrote: > On Sat, 2006-08-19 at 21:52 -0400, Robert L. Cochran wrote: > > At first, I liked Intel Core 2 Duo, but the motherboard selection doesn't > > seem great and it is very pricy. it's changing rapidly this week ;) > > The price is worth it in computing power. Core is the first, _full_ > Intel x86 redesign since the Pentium Pro. The NetBurst (P4) was a quick > refit of extending the pipes and doing virtually _no_ refactoring in the > ALU/FPU design (long story). eh that's so not the case ;) > > I still don't recommend Core 2 Duo or even Intel's forthcoming dual-FSB > processor for more than 2GiB on a server. Some may differ with me, but > offsetting the limitations with lots of L2/L3 cache doesn't go far > enough. They need a true interconnect and I/O MMU's on-processor. what does a "true interconnect" buy you in the <= 4 CPU case? Or an IOMMU if all your moderate and high bandwidth IO is 64 bit capable? From b.j.smith at ieee.org Sun Aug 20 20:27:04 2006 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Sun, 20 Aug 2006 16:27:04 -0400 Subject: AM2, X2, Opteron, or Opteron Socket F? In-Reply-To: <1156104522.23756.63.camel@laptopd505.fenrus.org> References: <008801c6c3fb$59d27450$3101a8c0@rclap> <1156099991.2989.55.camel@bert64.oviedo.smithconcepts.com> <1156104522.23756.63.camel@laptopd505.fenrus.org> Message-ID: <1156105624.2989.60.camel@bert64.oviedo.smithconcepts.com> On Sun, 2006-08-20 at 22:08 +0200, Arjan van de Ven wrote: > eh that's so not the case ;) Can you expand upon that? The NetBurst architecture had ALU and FPUs that were much slower per MHz than the PPro-P3. Slapping on SSE pipes is _not_ redesigning the FPU. > what does a "true interconnect" buy you in the <= 4 CPU case? > Or an IOMMU if all your moderate and high bandwidth IO is 64 bit > capable? Can you guarantee all your I/O is? -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith at ieee.org http://thebs413.blogspot.com --------------------------------------------------------- The world is in need of solutions. Unfortunately, people seem to be more interested in blindly aligning themselves with one of only two viewponts -- an "us v. them" debate that has nothing to do with finding an actual solution. From arjan at fenrus.demon.nl Sun Aug 20 20:31:32 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sun, 20 Aug 2006 22:31:32 +0200 Subject: AM2, X2, Opteron, or Opteron Socket F? In-Reply-To: <1156105624.2989.60.camel@bert64.oviedo.smithconcepts.com> References: <008801c6c3fb$59d27450$3101a8c0@rclap> <1156099991.2989.55.camel@bert64.oviedo.smithconcepts.com> <1156104522.23756.63.camel@laptopd505.fenrus.org> <1156105624.2989.60.camel@bert64.oviedo.smithconcepts.com> Message-ID: <1156105892.23756.69.camel@laptopd505.fenrus.org> On Sun, 2006-08-20 at 16:27 -0400, Bryan J. Smith wrote: > On Sun, 2006-08-20 at 22:08 +0200, Arjan van de Ven wrote: > > eh that's so not the case ;) > > Can you expand upon that? > > The NetBurst architecture had ALU and FPUs that were much slower per MHz > than the PPro-P3. they had a different design goal (mhz mhz mhz).. so your argument that they're the same is disproved just by your statement here already. > Slapping on SSE pipes is _not_ redesigning the FPU. > > > what does a "true interconnect" buy you in the <= 4 CPU case? > > Or an IOMMU if all your moderate and high bandwidth IO is 64 bit > > capable? > > Can you guarantee all your I/O is? you can if you pick your system with a tiny bit of care. Basically all gige nics are 64 bit capable (maybe a $4 nameless one excepted), and AHCI sata is too. All scsi that was made in the last decade is as well. Nobody makes high speed pci cards without it basically, and the on board stuff is normally ok as well. From b.j.smith at ieee.org Mon Aug 21 04:30:11 2006 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Mon, 21 Aug 2006 00:30:11 -0400 Subject: AM2, X2, Opteron, or Opteron Socket F? In-Reply-To: <1156105892.23756.69.camel@laptopd505.fenrus.org> References: <008801c6c3fb$59d27450$3101a8c0@rclap> <1156099991.2989.55.camel@bert64.oviedo.smithconcepts.com> <1156104522.23756.63.camel@laptopd505.fenrus.org> <1156105624.2989.60.camel@bert64.oviedo.smithconcepts.com> <1156105892.23756.69.camel@laptopd505.fenrus.org> Message-ID: <1156134611.2989.66.camel@bert64.oviedo.smithconcepts.com> On Sun, 2006-08-20 at 22:31 +0200, Arjan van de Ven wrote: > they had a different design goal (mhz mhz mhz).. No, that was the result. Their goal was to get the existing PPro base to beyond 1.0GHz (although they eventually got the originally timed design to 1.4GHz with a few async tweaks). The easiest way to do that was to extend the pipes and massively increase the staging to make timing at higher clocks easier. The result was massive inefficiency per MHz. > so your argument that they're the same is disproved just by your > statement here already. Umm, I'd expect someone without a semiconductor design background to assume that. ;-> > you can if you pick your system with a tiny bit of care. Basically all > gige nics are 64 bit capable (maybe a $4 nameless one excepted), and > AHCI sata is too. All scsi that was made in the last decade is as well. > Nobody makes high speed pci cards without it basically, and the on board > stuff is normally ok as well. There's more to memory mapped I/O than just the NIC and storage. ;-> But yes, I agree, with 2 or less sockets, it doesn't matter quite as much -- especially not with the newer Xeon designs. -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith at ieee.org http://thebs413.blogspot.com --------------------------------------------------------- The world is in need of solutions. Unfortunately, people seem to be more interested in blindly aligning themselves with one of only two viewponts -- an "us v. them" debate that has nothing to do with finding an actual solution. From arjan at fenrus.demon.nl Mon Aug 21 07:53:03 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 21 Aug 2006 09:53:03 +0200 Subject: AM2, X2, Opteron, or Opteron Socket F? In-Reply-To: <1156134611.2989.66.camel@bert64.oviedo.smithconcepts.com> References: <008801c6c3fb$59d27450$3101a8c0@rclap> <1156099991.2989.55.camel@bert64.oviedo.smithconcepts.com> <1156104522.23756.63.camel@laptopd505.fenrus.org> <1156105624.2989.60.camel@bert64.oviedo.smithconcepts.com> <1156105892.23756.69.camel@laptopd505.fenrus.org> <1156134611.2989.66.camel@bert64.oviedo.smithconcepts.com> Message-ID: <1156146783.23756.109.camel@laptopd505.fenrus.org> On Mon, 2006-08-21 at 00:30 -0400, Bryan J. Smith wrote: > On Sun, 2006-08-20 at 22:31 +0200, Arjan van de Ven wrote: > > they had a different design goal (mhz mhz mhz).. > > No, that was the result. > > Their goal was to get the existing PPro base to beyond 1.0GHz (although > they eventually got the originally timed design to 1.4GHz with a few > async tweaks). The easiest way to do that was to extend the pipes and > massively increase the staging to make timing at higher clocks easier. > The result was massive inefficiency per MHz. actually afaik the alu has some tricks doing even "half clock" stuff (which then gets used by HT) so it's not as black and white as you make it out to be > > > so your argument that they're the same is disproved just by your > > statement here already. > > Umm, I'd expect someone without a semiconductor design background to > assume that. ;-> do you mean me? I happen to have a semiconductor design background ;) > > > you can if you pick your system with a tiny bit of care. Basically all > > gige nics are 64 bit capable (maybe a $4 nameless one excepted), and > > AHCI sata is too. All scsi that was made in the last decade is as well. > > Nobody makes high speed pci cards without it basically, and the on board > > stuff is normally ok as well. > > There's more to memory mapped I/O than just the NIC and storage. ;-> yes there is. But all other high speed IO (I don't count floppy's or USB as such) is also 64 bit capable, at least if it's made in the last decade or so. From D.Mierzejewski at icm.edu.pl Mon Aug 21 09:21:24 2006 From: D.Mierzejewski at icm.edu.pl (Dominik 'Rathann' Mierzejewski) Date: Mon, 21 Aug 2006 11:21:24 +0200 Subject: AM2, X2, Opteron, or Opteron Socket F? In-Reply-To: <1156099991.2989.55.camel@bert64.oviedo.smithconcepts.com> References: <008801c6c3fb$59d27450$3101a8c0@rclap> <1156099991.2989.55.camel@bert64.oviedo.smithconcepts.com> Message-ID: <20060821092124.GB29397@ws-gradcol1.icm.edu.pl> On Sun, Aug 20, 2006 at 02:53:11PM -0400, Bryan J. Smith wrote: [...] > The 7600GT is a great buy right now. > > If you want a high-performance, passively cooled video, the 7600GS is > also nice and can be had for $90. It's great for set-top boxes because > of its built-in HDTV output and video decoding support in MPlayer. Could you elaborate on what you mean by video decoding support in MPlayer? There is no special support for nVidia's PureVideo (or whatever it is called) in MPlayer, if that's what you meant. At best, you can get some parts of MPEG-2 decoding done by the card using XvMC. Regards, -- Dominik 'Rathann' Mierzejewski Interdisciplinary Centre for Mathematical and Computational Modelling Warsaw University | http://www.icm.edu.pl | tel. +48 (22) 5540810 From b.j.smith at ieee.org Mon Aug 21 14:37:24 2006 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Mon, 21 Aug 2006 10:37:24 -0400 Subject: AM2, X2, Opteron, or Opteron Socket F? In-Reply-To: <20060821092124.GB29397@ws-gradcol1.icm.edu.pl> References: <008801c6c3fb$59d27450$3101a8c0@rclap> <1156099991.2989.55.camel@bert64.oviedo.smithconcepts.com> <20060821092124.GB29397@ws-gradcol1.icm.edu.pl> Message-ID: <1156171044.2989.82.camel@bert64.oviedo.smithconcepts.com> On Mon, 2006-08-21 at 11:21 +0200, Dominik 'Rathann' Mierzejewski wrote: > Could you elaborate on what you mean by video decoding support in MPlayer? > There is no special support for nVidia's PureVideo (or whatever it is > called) in MPlayer, if that's what you meant. At best, you can get some > parts of MPEG-2 decoding done by the card using XvMC. I know PureVideo isn't supported (at least not yet). I just meant there is GeForce 4+ decoding support and HDTV out has been pretty much standard on the 7 series, at least on the 7600 and higher. -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith at ieee.org http://thebs413.blogspot.com --------------------------------------------------------- The world is in need of solutions. Unfortunately, people seem to be more interested in blindly aligning themselves with one of only two viewponts -- an "us v. them" debate that has nothing to do with finding an actual solution. From b.j.smith at ieee.org Mon Aug 21 14:39:55 2006 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Mon, 21 Aug 2006 10:39:55 -0400 Subject: AM2, X2, Opteron, or Opteron Socket F? In-Reply-To: <1156146783.23756.109.camel@laptopd505.fenrus.org> References: <008801c6c3fb$59d27450$3101a8c0@rclap> <1156099991.2989.55.camel@bert64.oviedo.smithconcepts.com> <1156104522.23756.63.camel@laptopd505.fenrus.org> <1156105624.2989.60.camel@bert64.oviedo.smithconcepts.com> <1156105892.23756.69.camel@laptopd505.fenrus.org> <1156134611.2989.66.camel@bert64.oviedo.smithconcepts.com> <1156146783.23756.109.camel@laptopd505.fenrus.org> Message-ID: <1156171195.2989.86.camel@bert64.oviedo.smithconcepts.com> On Mon, 2006-08-21 at 09:53 +0200, Arjan van de Ven wrote: > actually afaik the alu has some tricks doing even "half clock" stuff > (which then gets used by HT) so it's not as black and white as you make > it out to be Yes. But it's not a full redesign either. They made a few tricks that were basically required to keep the simple pipe extensions from really being inefficient. E.g., HyperMarketing--er, HyperThreading is basically a NetBurst-only hack because of that inefficiency and the availability of so many unused stages. > do you mean me? I happen to have a semiconductor design background ;) Good. Then don't play games on my words. > yes there is. But all other high speed IO (I don't count floppy's or USB > as such) is also 64 bit capable, at least if it's made in the last > decade or so. But most people expect to be able to use all sorts of 32-bit devices without knowing it. -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith at ieee.org http://thebs413.blogspot.com --------------------------------------------------------- The world is in need of solutions. Unfortunately, people seem to be more interested in blindly aligning themselves with one of only two viewponts -- an "us v. them" debate that has nothing to do with finding an actual solution. From arjan at fenrus.demon.nl Mon Aug 21 14:59:39 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 21 Aug 2006 16:59:39 +0200 Subject: AM2, X2, Opteron, or Opteron Socket F? In-Reply-To: <1156171195.2989.86.camel@bert64.oviedo.smithconcepts.com> References: <008801c6c3fb$59d27450$3101a8c0@rclap> <1156099991.2989.55.camel@bert64.oviedo.smithconcepts.com> <1156104522.23756.63.camel@laptopd505.fenrus.org> <1156105624.2989.60.camel@bert64.oviedo.smithconcepts.com> <1156105892.23756.69.camel@laptopd505.fenrus.org> <1156134611.2989.66.camel@bert64.oviedo.smithconcepts.com> <1156146783.23756.109.camel@laptopd505.fenrus.org> <1156171195.2989.86.camel@bert64.oviedo.smithconcepts.com> Message-ID: <1156172379.23756.193.camel@laptopd505.fenrus.org> On Mon, 2006-08-21 at 10:39 -0400, Bryan J. Smith wrote: > > > yes there is. But all other high speed IO (I don't count floppy's or USB > > as such) is also 64 bit capable, at least if it's made in the last > > decade or so. > > But most people expect to be able to use all sorts of 32-bit devices > without knowing it. and they work even without IOMMU. Just that there is an extra memcpy involved on the kernel side. Which at not-highspeed rates is absolutely no big deal. Of course for anything high speed you don't want that, but those are as I said before 64 bit capable. From somsak_sr at thaigrid.or.th Thu Aug 24 05:19:28 2006 From: somsak_sr at thaigrid.or.th (Somsak Sriprayoonsakul) Date: Thu, 24 Aug 2006 12:19:28 +0700 Subject: [Fwd: [gfarm-discuss:03663] Re: 32bit application segmentation fault on 64bit] Message-ID: <44ED36E0.3070504@thaigrid.or.th> An HTML attachment was scrubbed... URL: From jay at scherrer.com Thu Aug 24 05:54:08 2006 From: jay at scherrer.com (Jay Scherrer) Date: Wed, 23 Aug 2006 22:54:08 -0700 Subject: [Fwd: [gfarm-discuss:03663] Re: 32bit application segmentation fault on 64bit] In-Reply-To: <44ED36E0.3070504@thaigrid.or.th> References: <44ED36E0.3070504@thaigrid.or.th> Message-ID: <44ED3F00.1010001@scherrer.com> Somsak Sriprayoonsakul wrote: > Hello, > > I'm trying to LD_PRELOAD an user-level file system library for > 32bit application on x86_64 machine (CentOS 4.3/RHEL4). Somehow the > application segfault everytime. I've install both 32bit and 64bit > libraries, and the test application is just a simple "ls" command (the > real one will be an proprietary animation rendering program so I can't > recompile it to 64bit). Below and attach file are all logs. > > My question is, is it possible to do this on x86_64? LD_PRELOAD > either 32bit or 64bit application, while providing all necessary > library for the applicaion. The answer from google seems to be yes, > but what've I done wrong? > > -------- Original Message -------- > Subject: [gfarm-discuss:03663] Re: 32bit application segmentation > fault on 64bit > Date: Fri, 18 Aug 2006 16:33:44 +0700 > From: Somsak Sriprayoonsakul > Reply-To: gfarm-discuss at apgrid.org > Organization: Thai National Grid Center > To: gfarm-discuss at apgrid.org > References: <452F37AE49199D49B1702D7D45038C4D6B0E13 at et.ad.sdsc.edu> > <44E2A2A1.3030804 at thaigrid.or.th> > <17635.2643.47481.577333 at srapc2586.sra.co.jp> > > > > The problem is less serious now since we successfully using gfarm-fuse > with the application. Anyways I've done strace log and here it is > > 1. Normal case > > [somsak_sr at anatta ~]$ LD_PRELOAD="/usr/lib64/gfarm/libc-not-hidden.so" > /bin/ls > bash clusterscores-1.0b0 globus-4.0.2-1.src.rpm > magi src > benchmark clusterscores-1.0b0.tar.gz globus_povray_stub > rocksmountdirty.sh tmp > bin clusterscores_result log > rpm usr > clusterscores gfarm-1.3.1-0.src.rpm ls > software work > [somsak_sr at anatta ~]$ LD_PRELOAD="/usr/lib/gfarm/libc-not-hidden.so" > $PWD/ls > Segmentation fault > [somsak_sr at anatta ~]$ file $PWD/ls > /home/somsak_sr/ls: ELF 32-bit LSB executable, Intel 80386, version 1 > (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped > [somsak_sr at anatta ~]$ > > 2. Invoke through 32bit bash > > [somsak_sr at anatta ~]$ file ./bash > ./bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for > GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped > [somsak_sr at anatta ~]$ file ./ls > ./ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for > GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped > [somsak_sr at anatta ~]$ export LD_PRELOAD="" > [somsak_sr at anatta ~]$ /bin/bash -c > "LD_PRELOAD='/usr/lib64/gfarm/libc-not-hidden.so' /bin/ls" > bash clusterscores-1.0b0 globus-4.0.2-1.src.rpm > magi src > benchmark clusterscores-1.0b0.tar.gz globus_povray_stub > rocksmountdirty.sh tmp > bin clusterscores_result log > rpm usr > clusterscores gfarm-1.3.1-0.src.rpm ls > software work > [somsak_sr at anatta ~]$ /bin/bash -c > "LD_PRELOAD='/usr/lib/gfarm/libc-not-hidden.so' $PWD/ls" > Segmentation fault > [somsak_sr at anatta ~]$ > > 3. strace log - strace log is attached wit this e-mail (it's too long). > Note that, I'm using 32bit strace. > > You'll see that I only set single file, libc-not-hidden, no gfarm-libs, > and it still segfault. I think this is not problem regarding gfarm anymore. > > > SODA Noriyuki wrote: > >>>>>> On Wed, 16 Aug 2006 11:44:17 +0700, > >>>>>> > > Somsak Sriprayoonsakul said: > > > > > >>> Maybe it's worthwhile to check out Gfarm-Fuse system. In our experience, > >>> the Gfarm-Fuse is much more stable in supporting preexisting > >>> applications. > >>> > > > > > >> Yes. Actually we already tested that and gfarm-fuse work great in term > >> of performance. Somehow gfarm-fuse only accept single user per mounted > >> file system, also it does not support lseek system call, which is > >> required by some application. That's why we're trying to use user-level > >> instead. > >> > > > > Hmm? What is the problem about lseek? > > As far as I know, lseek just does work with GfarmFS-FUSE. > > Thus, if you could allow your users to mount gfarm filesystem via > > GfarmFS-FUSE, certainly it could be an option as Wilfred said. > > > > If your problem with lseek was a data coherency problem, please try > > "-unbuf" option of GfarmFS-FUSE. > > > > > -- > ----------------------------------------------------------------------------------- > Somsak Sriprayoonsakul > > Thai National Grid Center > Software Industry Promotion Agency > Ministry of ICT, Thailand > somsak_sr at thaigrid.or.th > ----------------------------------------------------------------------------------- The real question is: are you calling both libraries at the same time. This used to be a problem with apt-get also. It would load both libraries X_32 and X_64 to cause a clash. Have you tried specifying either the X_32 or the X_64 only while compiling? Jay Scherrer From somsak_sr at thaigrid.or.th Thu Aug 24 08:30:55 2006 From: somsak_sr at thaigrid.or.th (Somsak Sriprayoonsakul) Date: Thu, 24 Aug 2006 15:30:55 +0700 Subject: [Fwd: [gfarm-discuss:03663] Re: 32bit application segmentation fault on 64bit] In-Reply-To: <44ED3F00.1010001@scherrer.com> References: <44ED36E0.3070504@thaigrid.or.th> <44ED3F00.1010001@scherrer.com> Message-ID: <44ED63BF.4040201@thaigrid.or.th> No, LD_PRELOAD is not specified by default. It'll be specified manually in the job script. Also, if I specify both, the 32bit application will refuse to load the 64bit lib (a error message "can not preload libxxx.so will appearred"). Jay Scherrer wrote: > Somsak Sriprayoonsakul wrote: >> Hello, >> >> I'm trying to LD_PRELOAD an user-level file system library for >> 32bit application on x86_64 machine (CentOS 4.3/RHEL4). Somehow the >> application segfault everytime. I've install both 32bit and 64bit >> libraries, and the test application is just a simple "ls" command >> (the real one will be an proprietary animation rendering program so I >> can't recompile it to 64bit). Below and attach file are all logs. >> >> My question is, is it possible to do this on x86_64? LD_PRELOAD >> either 32bit or 64bit application, while providing all necessary >> library for the applicaion. The answer from google seems to be yes, >> but what've I done wrong? >> >> -------- Original Message -------- >> Subject: [gfarm-discuss:03663] Re: 32bit application segmentation >> fault on 64bit >> Date: Fri, 18 Aug 2006 16:33:44 +0700 >> From: Somsak Sriprayoonsakul >> Reply-To: gfarm-discuss at apgrid.org >> Organization: Thai National Grid Center >> To: gfarm-discuss at apgrid.org >> References: >> <452F37AE49199D49B1702D7D45038C4D6B0E13 at et.ad.sdsc.edu> >> <44E2A2A1.3030804 at thaigrid.or.th> >> <17635.2643.47481.577333 at srapc2586.sra.co.jp> >> >> >> >> The problem is less serious now since we successfully using >> gfarm-fuse with the application. Anyways I've done strace log and >> here it is >> >> 1. Normal case >> >> [somsak_sr at anatta ~]$ >> LD_PRELOAD="/usr/lib64/gfarm/libc-not-hidden.so" /bin/ls >> bash clusterscores-1.0b0 globus-4.0.2-1.src.rpm >> magi src >> benchmark clusterscores-1.0b0.tar.gz globus_povray_stub >> rocksmountdirty.sh tmp >> bin clusterscores_result log >> rpm usr >> clusterscores gfarm-1.3.1-0.src.rpm ls >> software work >> [somsak_sr at anatta ~]$ LD_PRELOAD="/usr/lib/gfarm/libc-not-hidden.so" >> $PWD/ls Segmentation fault >> [somsak_sr at anatta ~]$ file $PWD/ls >> /home/somsak_sr/ls: ELF 32-bit LSB executable, Intel 80386, version 1 >> (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), >> stripped >> [somsak_sr at anatta ~]$ >> >> 2. Invoke through 32bit bash >> >> [somsak_sr at anatta ~]$ file ./bash >> ./bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for >> GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped >> [somsak_sr at anatta ~]$ file ./ls >> ./ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for >> GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped >> [somsak_sr at anatta ~]$ export LD_PRELOAD="" >> [somsak_sr at anatta ~]$ /bin/bash -c >> "LD_PRELOAD='/usr/lib64/gfarm/libc-not-hidden.so' /bin/ls" >> bash clusterscores-1.0b0 globus-4.0.2-1.src.rpm >> magi src >> benchmark clusterscores-1.0b0.tar.gz globus_povray_stub >> rocksmountdirty.sh tmp >> bin clusterscores_result log >> rpm usr >> clusterscores gfarm-1.3.1-0.src.rpm ls >> software work >> [somsak_sr at anatta ~]$ /bin/bash -c >> "LD_PRELOAD='/usr/lib/gfarm/libc-not-hidden.so' $PWD/ls" >> Segmentation fault >> [somsak_sr at anatta ~]$ >> >> 3. strace log - strace log is attached wit this e-mail (it's too >> long). Note that, I'm using 32bit strace. >> >> You'll see that I only set single file, libc-not-hidden, no >> gfarm-libs, and it still segfault. I think this is not problem >> regarding gfarm anymore. >> >> >> SODA Noriyuki wrote: >> >>>>>> On Wed, 16 Aug 2006 11:44:17 +0700, >> >>>>>> > Somsak Sriprayoonsakul >> said: >> > >> > >>> Maybe it's worthwhile to check out Gfarm-Fuse system. In our >> experience, >> >>> the Gfarm-Fuse is much more stable in supporting preexisting >> >>> applications. >> >>> > >> > >> Yes. Actually we already tested that and gfarm-fuse work great >> in term >> of performance. Somehow gfarm-fuse only accept single user >> per mounted >> file system, also it does not support lseek system >> call, which is >> required by some application. That's why we're >> trying to use user-level >> instead. >> >> > >> > Hmm? What is the problem about lseek? >> > As far as I know, lseek just does work with GfarmFS-FUSE. >> > Thus, if you could allow your users to mount gfarm filesystem via >> > GfarmFS-FUSE, certainly it could be an option as Wilfred said. >> > >> > If your problem with lseek was a data coherency problem, please try >> > "-unbuf" option of GfarmFS-FUSE. >> > >> >> -- >> ----------------------------------------------------------------------------------- >> >> Somsak Sriprayoonsakul >> >> Thai National Grid Center >> Software Industry Promotion Agency >> Ministry of ICT, Thailand >> somsak_sr at thaigrid.or.th >> ----------------------------------------------------------------------------------- >> > The real question is: are you calling both libraries at the same time. > This used to be a problem with apt-get also. It would load both > libraries X_32 and X_64 to cause a clash. > Have you tried specifying either the X_32 or the X_64 only while > compiling? > > Jay Scherrer > -- ----------------------------------------------------------------------------------- Somsak Sriprayoonsakul Thai National Grid Center Software Industry Promotion Agency Ministry of ICT, Thailand somsak_sr at thaigrid.or.th -----------------------------------------------------------------------------------