[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: coreutils-6.6 check failures on Itanium Linux

From: Matthew Woehlke
Subject: Re: coreutils-6.6 check failures on Itanium Linux
Date: Tue, 28 Nov 2006 10:21:36 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20061025 Thunderbird/ Mnenhy/

Bob Proulx wrote:
Matthew Woehlke wrote:
I get two 'make check' test failures on Itanium Linux.
The tests are mv/dir2dir and mv/no-target-dir. The dir2dir failure
seems to be a disagreement on error message, although given that the
error I see is the same as on no-target-dir, I'm still suspicious.

< mv: cannot move `b/t' to `a/t': Device or resource busy
> mv: cannot move `b/t' to `a/t': Directory not empty

Yes, both an error but different errors.  Can you reproduce the error
from the command line?  It would probably make further debugging

Yes, in fact I'd already tried that right after I saw the failure.
The interesting bits of strace:

access("a/t", W_OK) = 0
rename("b/t", "a/t") = -1 EBUSY (Device or resource busy)

+ mkdir -p d/sub empty src d2/sub e2
+ touch f
+ test 0 = 1
+ fail=0
+ mv -fT d empty
mv: cannot move `d' to `empty': Device or resource busy
+ fail=1

That seems really strange.  If I read that right it collapses to a
very simple thing that should not be failing.

  mkdir -p d/sub empty
  $builddir/src/mv -fT d empty
  strace -e file $builddir/src/mv -fT d empty

The above works for me on my ia64 system.  That one looks to be the
more interesting of the two failures.

Yes, agreed, and as mentioned I have no 'OS version' to test against, since /bin/mv does not understand -T. Anyway, strace said:

rename("d", "empty") = -1 EBUSY (Device or resource busy)

I am using a 2.6 kernel.  I think that will be the big difference.
But ia64 support really did not get stable in the linux kernel until
2.6 and so for ia64 I highly recommend upgrading.  This is very likely
an ia64 specific kernel problem.

Yes, it probably is, however in this case upgrading is not an option. This is the kernel version on which we support our product (in fact, we don't officially support 2.6.x on ia64 at all). Given the likelihood of anyone needing this to actually work (since rm'ing the target first is always an option), I'm fine with skipping the test (with, as was suggested, preferably a big warning message :-)). I'll try to take a look at the test changes that were posted.

Hmm, how would you feel about doing something similar on buggy Darwin kernels? (I.e. detecting buggy kernels and skipping tests rather than having them fail?)

Caution: keep out of reach of adults.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]