On Mon, 27 May 2024, Richard Kojedzinszky wrote:
> Dear Neil,
>
> I was running it on arm64, may that be the reason?
That could certainly explain it. I know x86_64 almost never needs
barriers, though I have seen cases where they matter. ppc64 is very
sensitive. A quick search suggests that arm
Dear Neil,
I was running it on arm64, may that be the reason?
Regards,
Richard
On May 27, 2024 4:02:32 AM GMT+02:00, NeilBrown wrote:
>On Sun, 26 May 2024, Richard Kojedzinszky wrote:
>> Dear Neil,
>>
>> According to my quick tests, your patch seems to fix this bug. Could you
>> also manage t
On Sun, 26 May 2024, Richard Kojedzinszky wrote:
> Dear Neil,
>
> According to my quick tests, your patch seems to fix this bug. Could you
> also manage to try my attached code, could you also reproduce the bug?
Thanks for testing.
I can run your test code but it isn't triggering the bug (90 mi
Dear Neil,
According to my quick tests, your patch seems to fix this bug. Could you
also manage to try my attached code, could you also reproduce the bug?
Thanks,
Richard
2024-05-24 07:29 időpontban Richard Kojedzinszky ezt írta:
Dear Neil,
I've applied your patch, and since then there are
Dear Neil,
I've applied your patch, and since then there are no lockups. Before
that my application reported a lockup in a minute or two, now it has
been running for half an hour, and still running.
Thanks,
Richard
2024-05-24 01:31 időpontban NeilBrown ezt írta:
On Fri, 24 May 2024, Richard
Dear Neil,
I've stripped the code more, which still triggers the bug for me. On
Bookworm, to get the binary, simply:
$ sudo apt-get install golang
$ go build .
And then give it an nfs mountpoint, e.g.:
$ ./ds /mnt/nfs
Meanwhile, I will try your patch too.
Regards,
Richard
2024-05-24 01:31
On Fri, 24 May 2024, Richard Kojedzinszky wrote:
> Dear devs,
>
> I am attaching a stripped down version of the little program which
> triggers the bug very quickly, in a few minutes in my test lab. It
> turned out that a single NFS mountpoint is enough. Just start the
> program giving it the N
Dear devs,
I am attaching a stripped down version of the little program which
triggers the bug very quickly, in a few minutes in my test lab. It
turned out that a single NFS mountpoint is enough. Just start the
program giving it the NFS mount as first argument. It will chdir there,
and do fil
Dear devs,
Now bisecting turned out that 3c59366c207e4c6c6569524af606baf017a55c61
is the bad commit for me. Strangely it only affects my dovecot process
accessing data over NFS.
Can you please confirm that this may be a bad commit?
My earlier attached programs may be used to demonstrate/trig
Dear NFS developers,
I am running multiple PODs on a Kubernetes node, they all mount
different NFS shares from the same nfs server. I started to notice
hangups in my dovecot process after I switched to Debian's kernel from
upstream 5.15. You can find Debian bugreport at
https://bugs.debian.or
10 matches
Mail list logo
