NetBSD Problem Report #48564
From www@NetBSD.org Fri Jan 31 21:41:52 2014
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id CE2E6A64A7
for <gnats-bugs@gnats.NetBSD.org>; Fri, 31 Jan 2014 21:41:52 +0000 (UTC)
Message-Id: <20140131214151.35CCDA64B2@mollari.NetBSD.org>
Date: Fri, 31 Jan 2014 21:41:51 +0000 (UTC)
From: jdbaker@mylinuxisp.com
Reply-To: jdbaker@mylinuxisp.com
To: gnats-bugs@NetBSD.org
Subject: 'tar' on evbmips-mips64el (LOONGSON) corrupts files extracted to NFS
X-Send-Pr-Version: www-1.0
>Number: 48564
>Category: port-evbmips
>Synopsis: 'tar' on evbmips-mips64el (LOONGSON) corrupts files extracted to NFS
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: port-evbmips-maintainer
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Jan 31 21:45:00 +0000 2014
>Closed-Date: Fri Sep 09 05:41:01 +0000 2016
>Last-Modified: Fri Sep 09 05:41:01 +0000 2016
>Originator: John D. Baker
>Release: NetBSD/evbmips-6.99.30 (evbmips-mips64el/LOONGSON)
>Organization:
>Environment:
NetBSD chalk.technoskunk.fur 6.99.30 NetBSD 6.99.30 (YEELOONG) #4: Thu Jan 30 19:42:48 CST 2014 sysop@verthandi.technoskunk.fur:/d0/build/current/obj/mips64el/sys/arch/evbmips/compile/YEELOONG evbmips
(Kernel config includes LOONGSON with additions for debugging and root
on NFS or SD card.)
>Description:
On my Lemote YEELOONG netbook, extracting a 'tar' archive to an NFS
destination yields files corrupted in the following fashion:
8192 bytes file data #0
8192 bytes 0x00
8192 bytes file data #2
8192 bytes 0x00
[...]
and the file is truncated to the nearest multiple of 8192 bytes.
The problem has so far only been observed with extracting files to an
NFS destination. Extracting an archive from NFS to local disk does not
corrupt data. Creating a tar archive on either local disk or NFS from
either NFS sources or local disk sources works correctly and does not
corrupt any member files.
This behavior was seen even in the early 6.99.x days (before LOONGSON
kernels had the prolonged build breakage).
>How-To-Repeat:
On evbmips-mips64el, particularly LOONGSON, particularly Lemote YEELOONG:
mount -t nfs server:/path/to/writable/dir /mnt
cd /etc
cp services /mnt/services-tmp
tar cf - services | tar xf - -C /mnt
ls -l /mnt/services* # observe size difference
cmp /mnt/services-tmp /mnt/services
Use 'hexdump -C /mnt/services | less' to observe file corruption
beginning at offset 0x2000-0x3fff, 0x6000-0x7fff, etc.
>Fix:
>Release-Note:
>Audit-Trail:
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-evbmips/48564: 'tar' on evbmips-mips64el (LOONGSON)
corrupts files extracted to NFS
Date: Sat, 26 Apr 2014 05:16:24 +0000
On Fri, Jan 31, 2014 at 09:45:00PM +0000, jdbaker@mylinuxisp.com wrote:
> On my Lemote YEELOONG netbook, extracting a 'tar' archive to an NFS
> destination yields files corrupted in the following fashion:
>
> 8192 bytes file data #0
> 8192 bytes 0x00
> 8192 bytes file data #2
> 8192 bytes 0x00
> [...]
>
> and the file is truncated to the nearest multiple of 8192 bytes.
Does this happen only with tar extracting files, or do any other
things that emit files exhibit the same behavior? Other versions of
tar?
Also, if you're in a position to try, can you ktrace it to find out
what size chunks tar is using to write the affected files?
(and what's the nfs server? netbsd?)
--
David A. Holland
dholland@netbsd.org
From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-evbmips/48564: 'tar' on evbmips-mips64el (LOONGSON) corrupts
files extracted to NFS
Date: Sat, 26 Apr 2014 14:11:15 -0500 (CDT)
On Sat, 26 Apr 2014, David Holland wrote:
> Does this happen only with tar extracting files, or do any other
> things that emit files exhibit the same behavior? Other versions of
> tar?
I have only observed it with 'tar' as installed from the release sets.
(Trying to run 'etcupdate' on my NFS-root installation was always
proposing bizarre and bogus changes to the various configuation files
and 'rc' scripts. Mounting a local disk partition on "/tmp" made it
work. 'etcupdate' needs a "-d" switch to select an arbitrary
destination/rootdir. 'postinstall' needs a "-t" switch to select an
alternate temporary directory, but those are issues for other PRs... ;)
A plain 'cp src dst' where "dst" is on NFS works fine. I did not explore
output redirection, which I should do when I next have opportunity. So
far, all other writes to NFS-resident files (such as with 'vi') work.
I have not tried other versions of 'tar'. It may be a challenge to
build other 'tar's due to the tendency of the native compiler to die
from bus error, segfault, etc. Perhaps I should look into the "distcc"
trick to farm the compiling out to the cross toolchain on my build host.
> Also, if you're in a position to try, can you ktrace it to find out
> what size chunks tar is using to write the affected files?
The machine is tied up at the moment, but when I next get a chance, I'll
see if I can do this.
> (and what's the nfs server? netbsd?)
The NFS server is NetBSD/i386-6.1_STABLE (soon to be switched to amd64).
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-evbmips/48564: 'tar' on evbmips-mips64el (LOONGSON) corrupts
files extracted to NFS
Date: Tue, 29 Apr 2014 17:05:23 -0500 (CDT)
On Sat, 26 Apr 2014, John D. Baker wrote:
> A plain 'cp src dst' where "dst" is on NFS works fine. I did not explore
> output redirection, which I should do when I next have opportunity. So
> far, all other writes to NFS-resident files (such as with 'vi') work.
File writes via output redirection fail in the same way as extraction with
'tar'. File copy with 'cp' works.
Editing a sufficiently large file with 'vi' and writing will produce
error messages about an unknown file format and claims that the file is
truncated, but later inspection indicates no obvious damage. (I was
editing my "~/.ssh/known_hosts" file at the time. Subsequent use of the
file by the ssh client succeeded--writing this very message over that
session.)
In the "changing too many things at once" department, these most recent
observations were made on a release built with "HAVE_GCC=48". So there's
further potential complication.
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-evbmips/48564: 'tar' on evbmips-mips64el (LOONGSON)
corrupts files extracted to NFS
Date: Mon, 2 Jun 2014 01:47:00 +0000
On Tue, Apr 29, 2014 at 10:10:00PM +0000, John D. Baker wrote:
> > A plain 'cp src dst' where "dst" is on NFS works fine. I did not explore
> > output redirection, which I should do when I next have opportunity. So
> > far, all other writes to NFS-resident files (such as with 'vi') work.
>
> File writes via output redirection fail in the same way as extraction with
> 'tar'. File copy with 'cp' works.
That's strange, since nfs shouldn't be able to tell the difference. I
guess it must have something to do with the block size being used for
writing. In which case it would be helpful if you could dig that out
(use ktrace) and see if there are any patterns.
> Editing a sufficiently large file with 'vi' and writing will produce
> error messages about an unknown file format and claims that the file is
> truncated, but later inspection indicates no obvious damage. (I was
> editing my "~/.ssh/known_hosts" file at the time. Subsequent use of the
> file by the ssh client succeeded--writing this very message over that
> session.)
This might be easier to track down, if it's repeatable.
> In the "changing too many things at once" department, these most recent
> observations were made on a release built with "HAVE_GCC=48". So there's
> further potential complication.
Most likely it's a pmap/cache control issue.
Which reminds me: if you don't have the fixes for PR 46890 yet, try
pulling that and see if it helps.
--
David A. Holland
dholland@netbsd.org
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-evbmips/48564: 'tar' on evbmips-mips64el (LOONGSON) corrupts files extracted to NFS
Date: Fri, 17 Jul 2015 15:39:29 +0200
This sounds a lot like an issue I see in -current on ERLITE (evbmips64-eb),
which prevents regular test runs on this arch:
I use the machine with / on NFS and in the test scripts, the "ticker" output
from atf is piped to tee writing it to a log file (on NFS).
The terminal output from tee(1) is complete, but the log file is missing
the last partial page (or something).
It is not 100% reproducable, but happens often (when the output piped
into tee(1) is big enough).
Martin
From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-evbmips/48564: 'tar' on evbmips-mips64el (LOONGSON) corrupts
files extracted to NFS
Date: Fri, 17 Jul 2015 22:21:26 -0500 (CDT)
As suggested earlier in this PR, below is the output of:
$ tar cf - svcs-tst.txt | ktruss tar xf - -C /mnt/tmp | tee tar-extract-nfs.ktruss
The file "svcs-tst.txt" is the first 32769 bytes (to a whole line) of
the "/etc/services" file, just big enough to illustrate the problem.
"/mnt/tmp" is an NFS-mounted filesystem and the target file is corrupted
with alternating 8KB blocks of source file data and zero-filled regions.
6130 1 ktruss fcntl(0x4, 0x3, 0) = 4194305, 6
6130 1 ktruss emul(netbsd32)
6130 1 ktruss netbsd32_fcntl(0x4, 0x4, 0x400001) = 0, 6
6130 1 tar netbsd32_execve("/usr/bin/tar", 0x7fff6cf8, 0x7fff6d10) JUSTRETURN
6130 1 tar emul(netbsd32)
6130 1 tar netbsd32_mmap(0, 0x8000, 0x3, 0x1002, 0xffffffff, 0, 0) = 0x787c8000
6130 1 tar netbsd32_open("/etc/ld.so.conf", 0, 0x787f4768) Err#2 ENOENT
6130 1 tar netbsd32_mmap(0, 0xc000, 0x3, 0x1002, 0xffffffff, 0, 0) = 0x787bc000
6130 1 tar netbsd32_open("/lib/libutil.so.7", 0, 0) = 3, 2021392384
6130 1 tar netbsd32___fstat50(0x3, 0x7fff6420) = 0, 2021392384
6130 1 tar netbsd32_mmap(0, 0xc000, 0x3, 0x1002, 0xffffffff, 0, 0) = 0x787b0000
6130 1 tar netbsd32_mmap(0, 0x4000, 0x1, 0x1, 0x3, 0, 0) = 0x787a0000
6130 1 tar netbsd32_munmap(0x787a0000, 0x4000) = 0, 1
6130 1 tar netbsd32_mmap(0, 0x2c000, 0x5, 0x10000002, 0x3, 0, 0) = 0x78780000
6130 1 tar netbsd32_mmap(0x787a4000, 0x4000, 0x3, 0x12, 0x3, 0, 0x14000) = 0x787a4000
6130 1 tar netbsd32_mmap(0x787a8000, 0x4000, 0x3, 0x1012, 0xffffffff, 0, 0) = 0x787a8000
6130 1 tar netbsd32_mprotect(0x78798000, 0xc000, 0) = 0, 98304
6130 1 tar netbsd32_close(0x3) = 0, 52
6130 1 tar netbsd32_open("/lib/libgcc_s.so.1", 0, 0) = 3, 17
6130 1 tar netbsd32___fstat50(0x3, 0x7fff6420) = 0, 17
6130 1 tar netbsd32_mmap(0, 0x4000, 0x1, 0x1, 0x3, 0, 0) = 0x78770000
6130 1 tar netbsd32_munmap(0x78770000, 0x4000) = 0, 1
6130 1 tar netbsd32_mmap(0, 0x24000, 0x5, 0x10000002, 0x3, 0, 0) = 0x78750000
6130 1 tar netbsd32_mmap(0x78770000, 0x4000, 0x3, 0x12, 0x3, 0, 0x10000) = 0x78770000
6130 1 tar netbsd32_mmap(0x78774000, 0, 0x3, 0x1012, 0xffffffff, 0, 0) = 0x78774000
6130 1 tar netbsd32_mprotect(0x78764000, 0xc000, 0) = 0, 81920
6130 1 tar netbsd32_close(0x3) = 0, 52
6130 1 tar netbsd32_open("/lib/libc.so.12", 0, 0) = 3, 18
6130 1 tar netbsd32___fstat50(0x3, 0x7fff6420) = 0, 18
6130 1 tar netbsd32_mmap(0, 0x4000, 0x1, 0x1, 0x3, 0, 0) = 0x78740000
6130 1 tar netbsd32_munmap(0x78740000, 0x4000) = 0, 1
6130 1 tar netbsd32_mmap(0, 0x1b8000, 0x5, 0x10000002, 0x3, 0, 0) = 0x78590000
6130 1 tar netbsd32_mmap(0x78700000, 0x38000, 0x3, 0x12, 0x3, 0, 0x160000) = 0x78700000
6130 1 tar netbsd32_mmap(0x78738000, 0x10000, 0x3, 0x1012, 0xffffffff, 0, 0) = 0x78738000
6130 1 tar netbsd32_mprotect(0x786f4000, 0xc000, 0) = 0, 1458176
6130 1 tar netbsd32_close(0x3) = 0, 52
6130 1 tar netbsd32_mmap(0, 0xc000, 0x3, 0x1002, 0xffffffff, 0, 0) = 0x78774000
6130 1 tar netbsd32__lwp_setprivate(0x78783008) = 0, 1
6130 1 tar _lwp_self() = 1, 2021392384
6130 1 tar netbsd32___sigprocmask14(0x1, 0x7fff6be0, 0x7fff6c50) = 0, -1
6130 1 tar netbsd32___sigprocmask14(0x3, 0x7fff6c50, 0) = 0, 2021442208
6130 1 tar netbsd32___sysctl(0x786dcec0, 0x2, 0x7873b990, 0x7fff6b60, 0, 0) = 0, 1
6130 1 tar _lwp_self() = 1, -1
6130 1 tar netbsd32___sigprocmask14(0x1, 0x7fff6b70, 0x7fff6c50) = 0, -1
6130 1 tar netbsd32___sigprocmask14(0x3, 0x7fff6c50, 0) = 0, 2021588992
6130 1 tar _lwp_self() = 1, 2020828392
6130 1 tar netbsd32___sigprocmask14(0x1, 0x7fff6b70, 0x7fff6c50) = 0, -1
6130 1 tar netbsd32___sigprocmask14(0x3, 0x7fff6c50, 0) = 0, 2021588992
6130 1 tar _lwp_self() = 1, 2021072312
6130 1 tar netbsd32___sigprocmask14(0x1, 0x7fff6b70, 0x7fff6c50) = 0, -1
6130 1 tar netbsd32___sigprocmask14(0x3, 0x7fff6c50, 0) = 0, 2021442204
6130 1 tar netbsd32_getrlimit(0x2, 0x7fff6c90) = 0, 7
6130 1 tar netbsd32_setrlimit(0x2, 0x7fff6c90) = 0, 7
6130 1 tar netbsd32_getrlimit(0x1, 0x7fff6c90) = 0, 7
6130 1 tar netbsd32_setrlimit(0x1, 0x7fff6c90) = 0, 7
6130 1 tar netbsd32_getrlimit(0x3, 0x7fff6c90) = 0, 7
6130 1 tar netbsd32_setrlimit(0x3, 0x7fff6c90) = 0, 7
6130 1 tar netbsd32_getrlimit(0x5, 0x7fff6c90) = 0, 7
6130 1 tar netbsd32_setrlimit(0x5, 0x7fff6c90) = 0, 7
6130 1 tar netbsd32___sigaction_sigtramp(0x1, 0x7fff6c78, 0x7fff6c60, 0x7863d040, 0x2) = 0, 2020855024
6130 1 tar netbsd32___sigaction_sigtramp(0xf, 0x7fff6c78, 0x7fff6c60, 0x7863d040, 0x2) = 0, 2020855024
6130 1 tar netbsd32___sigaction_sigtramp(0x2, 0x7fff6c78, 0x7fff6c60, 0x7863d040, 0x2) = 0, 2020855024
6130 1 tar netbsd32___sigaction_sigtramp(0x3, 0x7fff6c78, 0x7fff6c60, 0x7863d040, 0x2) = 0, 2020855024
6130 1 tar netbsd32___sigaction_sigtramp(0x18, 0x7fff6c78, 0x7fff6c60, 0x7863d040, 0x2) = 0, 2020855024
6130 1 tar netbsd32___sigaction_sigtramp(0xd, 0x7fff6c78, 0x7fff6c60, 0x7863d040, 0x2) = 0, 2020855024
6130 1 tar netbsd32___sigaction_sigtramp(0x19, 0x7fff6c78, 0x7fff6c60, 0x7863d040, 0x2) = 0, 2020855024
6130 1 tar netbsd32_open("/dev/tty", 0x2, 0x7fff6c60) = 3, 2020855024
6130 1 tar netbsd32_fcntl(0x3, 0x3, 0) = 2
6130 1 tar netbsd32_fcntl(0x3, 0x3, 0) = 2
6130 1 tar netbsd32_open(".", 0, 0) = 4, 268697600
6130 1 tar netbsd32___getcwd(0x10037678, 0x400) = 23, 7
6130 1 tar netbsd32___sysctl(0x7fff6790, 0x2, 0x7873ef00, 0x7fff6b98, 0, 0) = 0, 6
6130 1 tar netbsd32___sysctl(0x7fff66f0, 0x2, 0x78747240, 0x7fff66f8, 0, 0) = 0, 6
6130 1 tar netbsd32_readlink("/etc/malloc.conf", 0x7fff6790, 0x400) Err#2 ENOENT
6130 1 tar netbsd32_break(0x10045e10) = 0, 16384
6130 1 tar netbsd32_break(0x10045e10) = 0, -1
6130 1 tar netbsd32_break(0x10100000) = 0, -1
6130 1 tar netbsd32_mmap(0, 0x100000, 0x3, 0x14001002, 0xffffffff, 0, 0) = 0x78400000
6130 1 tar netbsd32___gettimeofday50(0x7fff6c30, 0) = 0, 7
6130 1 tar netbsd32___sigaction_sigtramp(0x1d, 0x7fff6c28, 0x7fff6c10, 0x7863d040, 0x2) = 0, 2020855024
6130 1 tar netbsd32_chdir("/mnt/tmp") = 0, 7
6130 1 tar netbsd32___getcwd(0x10037678, 0x400) = 9, -1
6130 1 tar netbsd32___fstat50(0, 0x100375c0) = 0, -1
6130 1 tar netbsd32_lseek(0, 0, 0, 0x1) Err#29 ESPIPE
6130 1 tar netbsd32_read(0, 0x10037e90, 0x7e00) = 16384, 7
"svcs-tst.txt\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
6130 1 tar netbsd32___gettimeofday50(0x7fff6b10, 0) = 0, 1954051118
6130 1 tar netbsd32___stat50("/etc/nsswitch.conf", 0x7fff6820) = 0, 1
6130 1 tar netbsd32_open("/etc/nsswitch.conf", 0x400000, 0x1b6) = 5, 2020865136
6130 1 tar netbsd32___fstat50(0x5, 0x7fff6580) = 0, 2020870496
6130 1 tar netbsd32_read(0x5, 0x78420000, 0x4000) = 621, 1
"#\t$NetBSD: nsswitch.conf,v 1.6 2009/10/25 00:17:06 tsarna Exp $\n#\n"
6130 1 tar netbsd32_read(0x5, 0x78420000, 0x4000) = 0, 2020870496
""
6130 1 tar _lwp_self() = 1, 2147443439
6130 1 tar netbsd32___sigprocmask14(0x1, 0x7fff6210, 0x7fff6280) = 0, -1
6130 1 tar netbsd32_open("/lib/nss_compat.so.0", 0, 0) Err#2 ENOENT
6130 1 tar netbsd32_open("/usr/lib/nss_compat.so.0", 0, 0) Err#2 ENOENT
6130 1 tar netbsd32___sigprocmask14(0x3, 0x7fff6280, 0) = 0
6130 1 tar _lwp_self() = 1, 2147443436
6130 1 tar netbsd32___sigprocmask14(0x1, 0x7fff6210, 0x7fff6280) = 0, -1
6130 1 tar netbsd32_open("/lib/nss_nis.so.0", 0, 0) Err#2 ENOENT
6130 1 tar netbsd32_open("/usr/lib/nss_nis.so.0", 0, 0) Err#2 ENOENT
6130 1 tar netbsd32___sigprocmask14(0x3, 0x7fff6280, 0) = 0
6130 1 tar _lwp_self() = 1, 2147443438
6130 1 tar netbsd32___sigprocmask14(0x1, 0x7fff6210, 0x7fff6280) = 0, -1
6130 1 tar netbsd32_open("/lib/nss_files.so.0", 0, 0) Err#2 ENOENT
6130 1 tar netbsd32_open("/usr/lib/nss_files.so.0", 0, 0) Err#2 ENOENT
6130 1 tar netbsd32___sigprocmask14(0x3, 0x7fff6280, 0) = 0
6130 1 tar _lwp_self() = 1, 2147443436
6130 1 tar netbsd32___sigprocmask14(0x1, 0x7fff6210, 0x7fff6280) = 0, -1
6130 1 tar netbsd32_open("/lib/nss_dns.so.0", 0, 0) Err#2 ENOENT
6130 1 tar netbsd32_open("/usr/lib/nss_dns.so.0", 0, 0) Err#2 ENOENT
6130 1 tar netbsd32___sigprocmask14(0x3, 0x7fff6280, 0) = 0
6130 1 tar netbsd32_close(0x5) = 0, 2020864856
6130 1 tar netbsd32___sysctl(0x7fff6790, 0x2, 0x787474e0, 0x7fff6798, 0, 0) = 0, 1
6130 1 tar netbsd32_open("/etc/group", 0x400000, 0x1b6) = 5, 2020865136
6130 1 tar netbsd32___stat50("/etc/nsswitch.conf", 0x7fff6820) = 0, 1
6130 1 tar netbsd32___fstat50(0x5, 0x7fff66a0) = 0, 2020855024
6130 1 tar netbsd32_lseek(0x5, 0, 0, 0x1) = 0, -1113715064
6130 1 tar netbsd32_lseek(0x5, 0, 0, 0) = 0, -1113714824
6130 1 tar netbsd32_read(0x5, 0x78420000, 0x4000) = 701, 2020870496
"wheel:*:0:root,sysop\ndaemon:*:1:daemon\nkmem:*:2:root\nsys:*:3:root"
6130 1 tar netbsd32___stat50("/etc/nsswitch.conf", 0x7fff6820) = 0, 1
6130 1 tar netbsd32___sysctl(0x7fff6770, 0x2, 0x787474e0, 0x7fff6778, 0, 0) = 0, 1
6130 1 tar geteuid() = 289
6130 1 tar geteuid() = 289
6130 1 tar netbsd32___stat50("/etc/pwd.db", 0x7fff6718) = 0, 2017690140
6130 1 tar netbsd32_open("/etc/pwd.db", 0x400000, 0) = 6, 2017690140
6130 1 tar netbsd32___fstat50(0x6, 0x7fff6718) = 0, 2017690140
6130 1 tar netbsd32_read(0x6, 0x78438040, 0x104) = 260, 2020385648
"\0\^F\^Ua\0\0\0\^B\0\0\^D\M-R\0\0\^P\0\0\0\0\f\0\0\^A\0\0\0\^A\0\0\0"
6130 1 tar netbsd32_pread(0x6, 0x7843d000, 0x1000, 0, 0x7000) = 4096, 2020855024
""\0\M-x\^O\M-t\^O\M-o\^O\M^\\^O\M^W\^OG\^OA\^O\M-u\^N\M-m\^N\M^W\^N"
6130 1 tar netbsd32_pread(0x6, 0x7843e000, 0x1000, 0, 0x1000) = 4096, 2020855024
"\^N\0\M-{\^O\M-/\^O\M-*\^OZ\^OU\^O\^E\^O\0\^O\M-/\^N\M-*\^NT\^NO\^N"
6130 1 tar netbsd32_pread(0x6, 0x7843f000, 0x1000, 0, 0x5000) = 4096, 2020855024
"\^Z\0\M-{\^O\M-2\^O\M--\^Oe\^O`\^O\^O\^O\a\^O\M-1\^N\M-*\^N^\^NW\^N\f"
6130 1 tar netbsd32___stat50("/etc/nsswitch.conf", 0x7fff6820) = 0, 1
6130 1 tar netbsd32_pread(0x6, 0x78440000, 0x1000, 0, 0x8000) = 4096, 2020855024
"\^X\0\M-{\^O\M-+\^O\M-&\^OP\^OK\^O\M-z\^N\M-u\^N\M-%\^N\240\^NW\^NR"
6130 1 tar netbsd32_mmap(0, 0x4000, 0x3, 0x1002, 0xffffffff, 0, 0) = 0x787ac000
6130 1 tar netbsd32_minherit(0x787ac000, 0x4000, 0x4) = 0, 2020855024
6130 1 tar netbsd32___sysctl(0x7fff6458, 0x2, 0x7fff6438, 0x7fff6460, 0, 0) = 0, 1
6130 1 tar netbsd32_open("svcs-tst.txt.OMgHxX", 0xa02, 0x180) = 7, 2147445152
6130 1 tar netbsd32___fstat50(0x7, 0x7fff6a30) = 0, -1
6130 1 tar netbsd32_write(0x7, 0x10038090, 0x2000) = 8192, 7
"# $NetBSD: services,v 1.98 2014/07/22 17:11:09 wiz Exp $\n# See also:"
6130 1 tar netbsd32_write(0x7, 0x1003a090, 0x1e00) = 7680, 512
" Defined TXT keys: u=<username> p=<password> path=<path>\nf"
6130 1 tar netbsd32_read(0, 0x10037e90, 0x7e00) = 16384, 5
" [Susie_Armstrong] [Susie_Armstron"
6130 1 tar netbsd32_write(0x7, 0x10037e90, 0x200) = 512
" [Susie_Armstrong] [Susie_Armstron"
6130 1 tar netbsd32_write(0x7, 0x10038090, 0x2000) = 8192
"e [Susie_Armstrong] [Susi"
6130 1 tar netbsd32_write(0x7, 0x1003a090, 0x1e00) = 7680, 512
" "
6130 1 tar netbsd32_read(0, 0x10037e90, 0x7e00) = 8192, 5
" "
6130 1 tar netbsd32_write(0x7, 0x10037e90, 0x200) = 512
" "
6130 1 tar netbsd32_write(0x7, 0x10038090, 0x1) = 1, 8191
"\n"
6130 1 tar netbsd32_close(0x7) = 0
6130 1 tar netbsd32_umask(0) = 18, 7
6130 1 tar netbsd32_umask(0x12) = 0, 7
6130 1 tar netbsd32_lchmod("svcs-tst.txt.OMgHxX", 0x1a4) = 0, 7
6130 1 tar netbsd32___lutimes50("svcs-tst.txt.OMgHxX", 0x7fff6aa8) = 0, 7
6130 1 tar netbsd32_rename("svcs-tst.txt.OMgHxX", "svcs-tst.txt") = 0, 7
6130 1 tar netbsd32_read(0, 0x7ffeeca0, 0x7e00) = 0, 4
""
6130 1 tar netbsd32___sigprocmask14(0x1, 0x10045e00, 0) = 0, 7
6130 1 tar netbsd32_close(0) = 0, 5
6130 1 tar _lwp_self() = 1, 2020893816
6130 1 tar netbsd32___sigprocmask14(0x1, 0x7fff6b60, 0x7fff6bd0) = 0, -1
6130 1 tar netbsd32___sigprocmask14(0x3, 0x7fff6bd0, 0) = 0, 2021588992
6130 1 tar _lwp_self() = 1, 2021064704
6130 1 tar netbsd32___sigprocmask14(0x1, 0x7fff6b60, 0x7fff6bd0) = 0, -1
6130 1 tar netbsd32___sigprocmask14(0x3, 0x7fff6bd0, 0) = 0, 2021588992
6130 1 tar _lwp_self() = 1, 2021064704
6130 1 tar netbsd32___sigprocmask14(0x1, 0x7fff6b60, 0x7fff6bd0) = 0, -1
6130 1 tar netbsd32___sigprocmask14(0x3, 0x7fff6bd0, 0) = 0, 2021588992
6130 1 tar _lwp_self() = 1, 2021064704
6130 1 tar netbsd32___sigprocmask14(0x1, 0x7fff6b60, 0x7fff6bd0) = 0, -1
6130 1 tar netbsd32___sigprocmask14(0x3, 0x7fff6bd0, 0) = 0, 2021442460
6130 1 tar netbsd32_exit(0)
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-evbmips/48564: 'tar' on evbmips-mips64el (LOONGSON) corrupts files extracted to NFS
Date: Mon, 20 Jul 2015 09:42:18 +0200
On Fri, Jul 17, 2015 at 03:39:29PM +0200, Martin Husemann wrote:
> It is not 100% reproducable, but happens often (when the output piped
> into tee(1) is big enough).
I can NOT reproduce it with simple things like:
cd $nfs_mounted_dir
tee < /usr/share/dict/words test | tail
tail test
Martin
From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-evbmips/48564: 'tar' on evbmips-mips64el (LOONGSON) corrupts
files extracted to NFS
Date: Mon, 20 Jul 2015 09:37:24 -0500 (CDT)
On Mon, 20 Jul 2015, Martin Husemann wrote:
> I can NOT reproduce it with simple things like:
>
> cd $nfs_mounted_dir
> tee < /usr/share/dict/words test | tail
> tail test
Likewise, I was unable to reproduce my observations copying my small
test fragment with I/O redirection:
$ cat svcs-tst.txt > /mnt/tmp/svcs-tst-cat.txt
Copying the entire "/etc/services" file that way, however, produced the
same corruption. I have a 'ktruss' output of that operation as well.
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
From: Nick Hudson <skrll@netbsd.org>
To: gnats-bugs@NetBSD.org, port-evbmips-maintainer@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, jdbaker@mylinuxisp.com
Cc:
Subject: Re: port-evbmips/48564: 'tar' on evbmips-mips64el (LOONGSON) corrupts
files extracted to NFS
Date: Sat, 9 Jul 2016 08:36:47 +0100
On 07/20/15 15:40, John D. Baker wrote:
> The following reply was made to PR port-evbmips/48564; it has been noted by GNATS.
>
> From: "John D. Baker" <jdbaker@mylinuxisp.com>
> To: gnats-bugs@NetBSD.org
> Cc:
> Subject: Re: port-evbmips/48564: 'tar' on evbmips-mips64el (LOONGSON) corrupts
> files extracted to NFS
> Date: Mon, 20 Jul 2015 09:37:24 -0500 (CDT)
>
> On Mon, 20 Jul 2015, Martin Husemann wrote:
>
> > I can NOT reproduce it with simple things like:
> >
> > cd $nfs_mounted_dir
> > tee < /usr/share/dict/words test | tail
> > tail test
>
> Likewise, I was unable to reproduce my observations copying my small
> test fragment with I/O redirection:
>
> $ cat svcs-tst.txt > /mnt/tmp/svcs-tst-cat.txt
>
> Copying the entire "/etc/services" file that way, however, produced the
> same corruption. I have a 'ktruss' output of that operation as well.
Does this still happen with a kernel from HEAD?
Nick
State-Changed-From-To: open->feedback
State-Changed-By: skrll@NetBSD.org
State-Changed-When: Sat, 09 Jul 2016 13:26:56 +0000
State-Changed-Why:
Feedback requested (recent pmap changes will likely fix this)
From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc: Nick Hudson <skrll@netbsd.org>
Subject: Re: port-evbmips/48564: 'tar' on evbmips-mips64el (LOONGSON) corrupts
files extracted to NFS
Date: Sat, 9 Jul 2016 12:47:35 -0500 (CDT)
On Sat, 9 Jul 2016, Nick Hudson wrote:
> Does this still happen with a kernel from HEAD?
With sources updated as of 201607070251Z, yes it still happens.
If this is not -current enough, I'll update and rebuild soon.
If it IS -current enough, is an update build insufficient?
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc: Nick Hudson <skrll@netbsd.org>
Subject: Re: port-evbmips/48564: 'tar' on evbmips-mips64el (LOONGSON) corrupts
files extracted to NFS
Date: Sun, 10 Jul 2016 16:35:30 -0500 (CDT)
On Sat, 9 Jul 2016, John D. Baker wrote:
> If this is not -current enough, I'll update and rebuild soon.
>
> If it IS -current enough, is an update build insufficient?
With sources updated as of 201607100243Z and a clean build to empty
OBJDIR and DESTDIR, the resulting system still exhibits the same problem,
built with each of GCC 4.8.5 and GCC 5.4.0.
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 10 Jul 2016 21:56:21 +0000
State-Changed-Why:
no such luck.
I have a vague recollection that this problem (untarring to nfs) has been
seen before and not on mips.
From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-evbmips/48564 ('tar' on evbmips-mips64el (LOONGSON) corrupts
files extracted to NFS)
Date: Sun, 10 Jul 2016 17:47:05 -0500 (CDT)
On Sun, 10 Jul 2016, dholland@NetBSD.org wrote:
> State-Changed-Why:
> no such luck.
>
> I have a vague recollection that this problem (untarring to nfs) has been
> seen before and not on mips.
I think its mentioned earlier in the PR, but perhaps I should reiterate
that the same type of corruption occurs when writing large files via
redirection of STDOUT, e.g.:
$ cat /etc/services > /path/to/nfs/services-cat
but copying with 'tar' pipeline vs 'cat' do not produce identically-broken
target files. They start out the same, but at some point the 'cat' copy
and the 'tar' copy get out of phase. They don't stay out of phase though.
A cursory examination seems to indicate that the 'cat' copy gets three 8KB
blocks of 00 bytes written in succession at some point and picks up with
the corresponding next block of file data.
They both still produce target files of identical size, reflecting the
size of the source file truncated to the nearest multiple of 8192 bytes.
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-evbmips/48564: 'tar' on evbmips-mips64el (LOONGSON) corrupts
files extracted to NFS
Date: Thu, 8 Sep 2016 18:17:12 -0500 (CDT)
Following an update built from sources of approximately 201609081500Z,
the problems described in this PR appear to have been fixed. The simple
test:
$ cd /etc
$ tar cf - services | tar xf - -C /path/to/NFS
$ cat services > /path/to/NFS/services-cat
produced target files that compared as identical with the source file.
Further, running 'etcupdate' with the default TMPDIR of "/tmp" being
on an NFS filesystem operated properly (previously, would suggest
preposterous modifications to files that were actually unchanged--the
modifications would have replaced valid data with blocks of 00 bytes).
Will test a gcc54-built system soon.
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-evbmips/48564: 'tar' on evbmips-mips64el (LOONGSON) corrupts
files extracted to NFS
Date: Thu, 8 Sep 2016 22:30:58 -0500 (CDT)
On Thu, 8 Sep 2016, John D. Baker wrote:
> Will test a gcc54-built system soon.
These problems appear fixed on a gcc54-built system as well.
Please try not to break it.
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
State-Changed-From-To: open->closed
State-Changed-By: skrll@NetBSD.org
State-Changed-When: Fri, 09 Sep 2016 05:41:01 +0000
State-Changed-Why:
Reported fixed.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home