Hi, This is continuation of a discussion at etoys-dev http://lists.squeakland.org/pipermail/etoys-dev/2010-October/005949.html Essentially, 4.x Linux VMs may fail with an error: Could not load library: /lib/libc.so.6: version `GLIBC_2.7' not found This is due to their dependency on libc6-2.7 or later. This version shipped in Ubuntu 8.04+ and kernels 2.6.24+. Machines with 256MB RAM running perfectly well on Ubuntu 7.10 became terribly slow when upgraded to 8.04 (google for "ubuntu hardy slow"). Linux kernel degraded poorly when faced with memory pressure caused by increased working set of 8.04. People with 256MB RAM systems (e.g. schools) could not upgrade to distros with libc6 v2.7+ without upgrading their hardware. XOs have 256MB RAMs and so do virtual machines that run in qemu or kvm. So the increased requirement may affect these deployments. Has anyone faced this issue in Squeak v4.1 on production machines? Subbu |
On Fri, Oct 15, 2010 at 11:09:36PM +0530, K. K. Subramaniam wrote: > > Hi, > > This is continuation of a discussion at etoys-dev > http://lists.squeakland.org/pipermail/etoys-dev/2010-October/005949.html > > Essentially, 4.x Linux VMs may fail with an error: > > Could not load library: /lib/libc.so.6: version `GLIBC_2.7' not found > > This is due to their dependency on libc6-2.7 or later. This version shipped in > Ubuntu 8.04+ and kernels 2.6.24+. Machines with 256MB RAM running perfectly > well on Ubuntu 7.10 became terribly slow when upgraded to 8.04 (google for > "ubuntu hardy slow"). Linux kernel degraded poorly when faced with memory > pressure caused by increased working set of 8.04. People with 256MB RAM > systems (e.g. schools) could not upgrade to distros with libc6 v2.7+ without > upgrading their hardware. > > XOs have 256MB RAMs and so do virtual machines that run in qemu or kvm. So the > increased requirement may affect these deployments. > > Has anyone faced this issue in Squeak v4.1 on production machines? Well I certainly noticed this on my own old laptop (but I compile my own VM's and did not pay much attention to it). Certainly we should find a way to continue providing working VMs for XOs and for older PCs in schools. A couple of questions to clarify the issue: For XOs and for all Etoys users, the images are not closure enabled, and therefore only the traditional interpreter VM (not Cog) is an issue at this time. Thus for the next round of VMs to be released (timing aligned with Squeak 4.2 release), there is no need to provide a Linux Cog VM compiled with the older libraries. Is this correct? I know that there is an Etoys release being prepared right now. What is the timeline for finding a solution to this issue? Thanks for bringing this up. Dave |
On Saturday 16 Oct 2010 3:09:02 am David T. Lewis wrote: > For XOs and for all Etoys users, the images are not closure enabled, > and therefore only the traditional interpreter VM (not Cog) is an > issue at this time. Thus for the next round of VMs to be released > (timing aligned with Squeak 4.2 release), there is no need to provide > a Linux Cog VM compiled with the older libraries. Is this correct? The defect has to do with any VM linked against libc6-2.7 or later running in 256MB machines with disks. It would apply to Cog VM too. The manifest behavior is responsiveness that goes from millisecs to seconds :-( :-(. We have to make a special version for older configurations. > I know that there is an Etoys release being prepared right now. What > is the timeline for finding a solution to this issue? Unknown at present. The defect is not in Etoys but in linux kernel. The defect is very tricky and triggers a fault only during disk i/o operations under low memory conditions. It was tracked down only in Dec 2009. Those who are interested in kernel and i/o scheduling may want to follow the detective trail in http://lkml.org/lkml/2009/12/7/237 thread. Subbu |
Free forum by Nabble | Edit this page |