On Fri, Oct 30, 2020 at 10:55:56AM -0700, Chuck Silvers wrote:
> On Tue, Oct 27, 2020 at 01:18:26PM +0100, Thomas Klausner wrote:
> > I'm still running a September 17 kernel, and I see rare NFS corruption.
> >
> > Basically, I'm rezipping a lot of zip archives (~2TB) that are on NFS
> > and four o
On Tue, Oct 27, 2020 at 01:18:26PM +0100, Thomas Klausner wrote:
> I'm still running a September 17 kernel, and I see rare NFS corruption.
>
> Basically, I'm rezipping a lot of zip archives (~2TB) that are on NFS
> and four of them had blocks of 0 bytes afterwards, not much. For the
> ones I kept,
On Sun, Oct 18, 2020 at 05:59:11PM +0900, Rin Okuyama wrote:
> On 2020/10/18 2:25, Anthony Mallet wrote:
> > I made some progress on this, and could apparently fix something. See
> > attached a sample script that reliably reproduces the issue.
> >
> > To summarize: when the script is run on the NF
On Sunday 18 Oct 2020, at 17:59, Rin Okuyama wrote:
> Thank you very much for providing test case. I can reproduce the
> problem on amd64 and i386. I've reverted that commit.
I've been running 9.99.74 / Oct 18 for more than 12h and I did not see
any issues so far.
Thanks for your help!
On 2020/10/19 1:56, Reinoud Zandijk wrote:
On Sun, Oct 18, 2020 at 05:59:11PM +0900, Rin Okuyama wrote:
On 2020/10/18 2:25, Anthony Mallet wrote:
As Chuck suggested in another e-mail, reverting uvm_bio.c to previous 1.121
$NetBSD: uvm_bio.c,v 1.121 2020/07/09 09:24:32 rin Exp $
appears to fix t
On Sun, Oct 18, 2020 at 05:59:11PM +0900, Rin Okuyama wrote:
> On 2020/10/18 2:25, Anthony Mallet wrote:
> > As Chuck suggested in another e-mail, reverting uvm_bio.c to previous 1.121
> > $NetBSD: uvm_bio.c,v 1.121 2020/07/09 09:24:32 rin Exp $
> > appears to fix the issue (at least the test scrip
/uvm_bio.c#rev1.122
If this commit is applied to NFS client, changes to files in client
side are sometimes invisible in server side, which results in file
corruption.
Demonstrated by test code provided by Anthony Mallet:
https://mail-index.netbsd.org/current-users/2020/10/17/msg039708.html
Whethe
On Friday 16 Oct 2020, at 11:05, Anthony Mallet wrote:
> For some databases (especially those in the firefox profile, but not
> only), inserting a row in some tables (not all) from a NFS client does
> not update the file on the server.
I made some progress on this, and could apparently fix somethi
I’ve been running 9.99.72 on an amd64 system for since it was posted, and I
have my /home mounted on an NFS share. I’m not using sqlite3, just a pretty
basic installation. The disk I’m running from is an SSD. Just leaving the
system sit idle over a few days to week or so and doing nothing mor
Hi,
As wiz@ and reinoud@ already mentionned¹, I also experience frequent
corruption with sqlite3 databases over NFS. There is no concurrent
access to the database (single NFS client).
For some databases (especially those in the firefox profile, but not
only), inserting a row in some tables (not a
Thanks, I kind of suspected that but noticed the build farm has been running
into some problems building an amd64 snapshot newer than the one I have. I’ll
give it another try when there’s a new one available rather than trying to
apply the mod and building my own.
-bob
On Jan 19, 2020, at 1:
On Sun, Jan 19, 2020 at 12:21:06PM -0600, Robert Nestor wrote:
> Thanks! I followed Andrew?s instructions and got a photo of the stack
> trace and sent it to him directly. Hope it helps him figure out what?s
> happening.
Thanks for the photo. This is a problem in the DRM code. It was fixed a
Thanks! I followed Andrew’s instructions and got a photo of the stack trace
and sent it to him directly. Hope it helps him figure out what’s happening.
-bob
On Jan 19, 2020, at 11:29 AM, Greg Troxel wrote:
> Robert Nestor writes:
>
>> Sorry for not being specific. When I do the shutdown o
Robert Nestor writes:
> Sorry for not being specific. When I do the shutdown on a subsequent
> reboot all the filesystems are dirty forcing fsck to run. Sometimes
> it finds some minor errors and repairs them.
ok - I am trying to separate "corruption", which means that files that
were not in t
t Nestor writes:
> >
> >> I?ve downloaded and installed 9.99.38 (Jan 17 build) and the original
> >> problem I was seeing with ?git? is gone. However, I?m now seeing a
> >> new problem with file corruption, but it only seems to happen when I
> >> do a no
t Nestor writes:
> > >
> > >> I?ve downloaded and installed 9.99.38 (Jan 17 build) and the original
> > >> problem I was seeing with ?git? is gone. However, I?m now seeing a
> > >> new problem with file corruption, but it only seems to happen when I
, Greg Troxel wrote:
> Robert Nestor writes:
>
>> I’ve downloaded and installed 9.99.38 (Jan 17 build) and the original
>> problem I was seeing with “git” is gone. However, I’m now seeing a
>> new problem with file corruption, but it only seems to happen when I
>>
Robert Nestor writes:
> I’ve downloaded and installed 9.99.38 (Jan 17 build) and the original
> problem I was seeing with “git” is gone. However, I’m now seeing a
> new problem with file corruption, but it only seems to happen when I
> do a normal shutdown. If I do a “shutdow
I’ve downloaded and installed 9.99.38 (Jan 17 build) and the original problem I
was seeing with “git” is gone. However, I’m now seeing a new problem with file
corruption, but it only seems to happen when I do a normal shutdown. If I do a
“shutdown -r now” to shutdown and reboot the system I
nstalled NetBSD-9.99.38 (Jan 15th build) on another disk. I
>> copied my current copy of pkgsrc over to the new disk to build some of the
>> packages I use under the new system. When I went into the pkgsrc/wip
>> directory and did a “git pull -r” it complained about file corrupti
qemu-nvmm.
>
> This morning I installed NetBSD-9.99.38 (Jan 15th build) on another disk. I
> copied my current copy of pkgsrc over to the new disk to build some of the
> packages I use under the new system. When I went into the pkgsrc/wip
> directory and did a “git pull -r” it complain
qemu-nvmm.
>
> This morning I installed NetBSD-9.99.38 (Jan 15th build) on another disk. I
> copied my current copy of pkgsrc over to the new disk to build some of the
> packages I use under the new system. When I went into the pkgsrc/wip
> directory and did a “git pull -r” it complain
nt copy of pkgsrc over to the new disk to build some of
> the packages I use under the new system. When I went into the pkgsrc/wip
> directory and did a “git pull -r” it complained about file corruption. I
> tired the same command in the pkgsrc/wip directory on my 9.99.17 system and
> got
. I
copied my current copy of pkgsrc over to the new disk to build some of the
packages I use under the new system. When I went into the pkgsrc/wip directory
and did a “git pull -r” it complained about file corruption. I tired the same
command in the pkgsrc/wip directory on my 9.99.17 system and
On Fri, Apr 28, 2017 at 01:36:52PM +0100, Patrick Welche wrote:
> Netbooting 7.1, a cvs co through re(4) appears to be clean.
> Unfortunately I can't run 7.1, as it's a new computer which only
> has USB3 ports, so no keyboard on 7.1.
Having tried sufficient straws including a BIOS update, I can no
On 29 April 2017 at 08:45, Thomas Mueller wrote:
> from Patrick Welche and David Brownlee:
>
>> > Netbooting 7.1, a cvs co through re(4) appears to be clean.
>> > Unfortunately I can't run 7.1, as it's a new computer which only
>> > has USB3 ports, so no keyboard on 7.1.
>
>> In case it helps the
from Patrick Welche and David Brownlee:
> > Netbooting 7.1, a cvs co through re(4) appears to be clean.
> > Unfortunately I can't run 7.1, as it's a new computer which only
> > has USB3 ports, so no keyboard on 7.1.
> In case it helps the latest netbsd-7 branch builds from
> http://nycdn.netbsd.o
n Mon, Apr 24, 2017 at 05:13:45PM +0100, Robert Swindells wrote:
> > > > >
> > > > > Patrick Welche wrote:
> > > > > >The "file corruption" problem seems to be a problem with re(4):
> > > > >
> > > > > [snip]
gt; > >
> > > > Patrick Welche wrote:
> > > > >The "file corruption" problem seems to be a problem with re(4):
> > > >
> > > > [snip]
> > > >
> > > > >Instead of using
> > > > >
> >
On Tue, Apr 25, 2017 at 04:04:25PM +0100, Patrick Welche wrote:
> On Mon, Apr 24, 2017 at 05:47:50PM +0100, Patrick Welche wrote:
> > On Mon, Apr 24, 2017 at 05:13:45PM +0100, Robert Swindells wrote:
> > >
> > > Patrick Welche wrote:
> > > >The "fi
On Mon, Apr 24, 2017 at 05:47:50PM +0100, Patrick Welche wrote:
> On Mon, Apr 24, 2017 at 05:13:45PM +0100, Robert Swindells wrote:
> >
> > Patrick Welche wrote:
> > >The "file corruption" problem seems to be a problem with re(4):
> >
> > [snip]
>
Patrick Welche wrote:
>The "file corruption" problem seems to be a problem with re(4):
[snip]
>Instead of using
>
>re0 at pci3 dev 0 function 0: RealTek 8168/8111 PCIe Gigabit Ethernet (rev.
>0x07)
>re0: interrupting at msi3 vec 0
>rgephy0 at re0 phy 7: RTL81
On Mon, Apr 24, 2017 at 05:13:45PM +0100, Robert Swindells wrote:
>
> Patrick Welche wrote:
> >The "file corruption" problem seems to be a problem with re(4):
>
> [snip]
>
> >Instead of using
> >
> >re0 at pci3 dev 0 function 0: RealTek 8168/
The "file corruption" problem seems to be a problem with re(4):
I built a release with code from Fri Feb 17 04:31:34 2017 +
Two rounds of
cvs -d:pserver:anon...@anoncvs.netbsd.org:/cvsroot co -D2017.04.04.13.30.00 src
both gave "corrupted files". (This rules out &qu
On Fri, Apr 07, 2017 at 06:50:29PM +0100, Patrick Welche wrote:
> On Fri, Apr 07, 2017 at 10:42:20AM -0400, Ian D. Leroux wrote:
> > On Wed, Apr 5, 2017, at 08:01, Patrick Welche wrote:
> > > It seems something recentish broke FFS, and WAPBL is blameless...
> >
> > I won't be much use to you, but
Fwiw, I am (and have been) running constantly-updated head of -current and
no obvious issues on my ffs/wapbl SSD.
-bch
On Apr 7, 2017 13:42, "Ian D. Leroux" wrote:
> On Wed, Apr 5, 2017, at 08:01, Patrick Welche wrote:
> > It seems something recentish broke FFS, and WAPBL is blameless...
>
> I
On Fri, 7 Apr 2017 21:05:12 + (UTC) chris...@astron.com (Christos
Zoulas) wrote:
> I am running current as of yesterday on both amd64 and i386 and it
> seems to be just fine.
Thanks all for the reassuring evidence. Updating now.
--
IDL
In article <20170407175029.GA884@quark>,
Patrick Welche wrote:
>On Fri, Apr 07, 2017 at 10:42:20AM -0400, Ian D. Leroux wrote:
>> On Wed, Apr 5, 2017, at 08:01, Patrick Welche wrote:
>> > It seems something recentish broke FFS, and WAPBL is blameless...
>>
>> I won't be much use to you, but coul
On Wed, Apr 5, 2017, at 08:01, Patrick Welche wrote:
> It seems something recentish broke FFS, and WAPBL is blameless...
I won't be much use to you, but could you file a PR or keep current-
users@ advised of any progress on this? I'd rather not update my main
machine until this is resolved ...
T
On Fri, Apr 07, 2017 at 10:42:20AM -0400, Ian D. Leroux wrote:
> On Wed, Apr 5, 2017, at 08:01, Patrick Welche wrote:
> > It seems something recentish broke FFS, and WAPBL is blameless...
>
> I won't be much use to you, but could you file a PR or keep current-
> users@ advised of any progress on t
On Tue, Apr 04, 2017 at 02:29:39PM +0100, Patrick Welche wrote:
> I just did a fresh cvs checkout of src, into /usr/src which is on:
>
> wd1:
> /dev/wd1e on /usr type ffs (log, local)
> cylgrp dynamic inodes FFSv2 sblock FFSv2 fslevel 5
>
> Without attempting any builds, and just looking
I just did a fresh cvs checkout of src, into /usr/src which is on:
wd1:
/dev/wd1e on /usr type ffs (log, local)
cylgrp dynamic inodes FFSv2 sblock FFSv2 fslevel 5
Without attempting any builds, and just looking at the fresh checkout,
according to "file":
/usr/src/external/bsd/llvm/dist/l
42 matches
Mail list logo
