[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22624: [bug-coreutils] coreutils-8.25: big success, but problem on G
From: |
Nelson H. F. Beebe |
Subject: |
bug#22624: [bug-coreutils] coreutils-8.25: big success, but problem on GNU/Hurd |
Date: |
Wed, 10 Feb 2016 14:57:53 -0700 |
I'm pleased to report successful builds, validations, and
installations of coreutils-8.25 on at least 72 of the 77 machines in
our lab running various flavors of Unix.
The one problematic system is GNU/Hurd, aka Debian GNU/Hurd
stretch/sid. We ran Hurd on VMware/ESX for a couple of years, but it
was never stable, and crashed or hung every few hours. Every such
failure requires a manual fsck on reboot, preventing automated
recovery.
Last summer, I moved Hurd to virt-manager + QEMU on my desktop, where
it has proved substantially more stable, sometimes staying up for many
days.
Debian GNU/Hurd has about 47,580 packages available in the Debian
apt-get system, so others have clearly done a lot of work on it.
There are major, and reasonably-current, packages like these available
via apt-get:
/usr/bin/clang-3.6 --version
Debian clang version 3.6.2-1 (tags/RELEASE_362/final) (based on LLVM
3.6.2)
Target: i386-pc--gnu
Thread model: posix
/usr/bin/gcc --version
gcc (Debian 5.2.1-26) 5.2.1 20151125
/bin/ls --version
ls (GNU coreutils) 8.23
With builds of coreutils-8.25 at my site, the "make check" run ALWAYS
hangs Hurd, requiring a reboot and an fsck.
I've just made further experiments that confirm that the hang always
happens in the same place, about 60 seconds after starting this
command:
$ make check
... lots of PASS reports, except FAIL in tests/misc/kill.sh and
tests/split/filter.sh ...
PASS: tests/split/b-chunk.sh
PASS: tests/split/fail.sh
PASS: tests/split/lines.sh
line-bytes.sh: skipped test: this shell lacks ulimit support
SKIP: tests/split/line-bytes.sh
Timeout, server 192.168.122.66 not responding.
The default memory size is 1GB, but today I got the same results when
the VM was restarted with 2GB and with 8GB.
I have also run the "make check" in a console window, eliminating
possible network timeouts from the dataflow, with "top" running in a
separate xterm + ssh window, and got this output at the point of the
hang:
# in console window
SKIP: tests/split/line-bytes.sh
no more room for vm_map_find_entry in 8022b080
no more room for kmem_realloc in 8022b080
/hurd/mach-defpage: panic: (default pager):
# in simulataneous xterm window
% top
top - 14:10:49 up 10 min, 8 users, load average: 0.55, 1.33, 1.46
Tasks: 74 total, 2 running, 69 sleeping, 0 stopped, 0 zombie
%Cpu(s): 54.3 us, 0.0 sy, 0.0 ni, 45.7 id, 0.0 wa, 0.0 hi,
0.0 si
KiB Mem: 1900540 total, 1550052 used, 350488 free, 0 buffers
KiB Swap: 0 total, 0 used, 0 free. 1792 cached
Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
1015 beebe 20 0 151616 144 0 S 0.0 0.0 0:00.02
-bash
1081 beebe 30 10 150060 148 0 S 0.0 0.0 0:00.00 time
The coreutils developers should probably not view this as a coreutils
bug, because Hurd has many oddities, and the pager-panic report
definitely suggests a kernel issue.
However, because coreutils has long been built and distributed on
Hurd, I thought it would be worthwhile to at least report my
experience, in the hope that other list members with GNU/Hurd systems
might be able to report their own result with the latest coreutils.
I unfortunately do not have any spare physical hardware on which to
run GNU/Hurd; my only access to it is on virtual machines.
My desktop is currently running 18 different VMs, on top of its CentOS
7 base operating system. Apart from GNU/Hurd, all of the others have
been perfectly stable for 4 to 6 months of operation, so I think that
it is unlikely that the above failure is due to the virtual machine
environment. There are two significant differences, however: the
others have virtual SATA disks and are 64-bit systems, whereas Hurd
supports only (virtual) EIDE disks, and is a 32-bit system. Our
suspicions of the instability of Hurd on VMware/ESX have to do with
the EIDE virtual disk system, which may have been less well tested
than SATA.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: address@hidden -
- 155 S 1400 E RM 233 address@hidden address@hidden -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
- bug#22624: [bug-coreutils] coreutils-8.25: big success, but problem on GNU/Hurd,
Nelson H. F. Beebe <=
- bug#22624: [bug-coreutils] coreutils-8.25: big success, but problem on GNU/Hurd, Paul Eggert, 2016/02/10
- bug#22624: [bug-coreutils] coreutils-8.25: big success, but problem on GNU/Hurd, Bernhard Voelker, 2016/02/11
- bug#22624: [bug-coreutils] coreutils-8.25: big success, but problem on GNU/Hurd, Nelson H. F. Beebe, 2016/02/11
- bug#22624: [bug-coreutils] coreutils-8.25: big success, but problem on GNU/Hurd, Paul Eggert, 2016/02/11
- bug#22624: [bug-coreutils] coreutils-8.25: big success, but problem on GNU/Hurd, Pádraig Brady, 2016/02/11
- bug#22624: [bug-coreutils] coreutils-8.25: big success, but problem on GNU/Hurd, Paul Eggert, 2016/02/12
- bug#22624: [bug-coreutils] coreutils-8.25: big success, but problem on GNU/Hurd, Pádraig Brady, 2016/02/13
bug#22624: [bug-coreutils] coreutils-8.25: big success, but problem on GNU/Hurd, Pádraig Brady, 2016/02/10