Hi guys,
Any progresses for this issue?
Regards,
Alvin Chen
Dell | Comercial Client Group
office +86-10-82862506, fax +86-10-82861554, Dell Lync 8672506
weike_c...@dell.com
Internal Use - Confidential
-Original Message-
From: Konstantin Belousov
Sent: 2022年2月24日 9:24
To: Alexander
Yes, I spoke to soon too. Often it crashes as soon as I start a parallel
poudriere build. But this time it went very far. As soon as nightly backups
kicked in it was game over again.
I had read the mail of Bob on the arm@ ML. But I wanted to let the conclusion
that it is about the same problem
Hello,
For one of my projects, I've received a patch to our implementation of fts(3)
which does not check for readdir(3) errors. The patch seemed obvious and
looked OK to me so I merged it to my project.
I think we should merge it to FreeBSD too so I've opened a PR (with the patch)
here:
http
Dear Mark Johnston,
I did some binary search in the kernels and came to the conclusion that
https://cgit.freebsd.org/src/commit/?id=1517b8d5a7f58897200497811de1b18809c07d3e
still works and
https://cgit.freebsd.org/src/commit/?id=407c34e735b5d17e2be574808a09e6d729b0a45a
panics.
I suspect your
On 2022-Mar-7, at 05:46, Ronald Klop wrote:
> Dear Mark Johnston,
>
> I did some binary search in the kernels and came to the conclusion that
> https://cgit.freebsd.org/src/commit/?id=1517b8d5a7f58897200497811de1b18809c07d3e
> still works and
> https://cgit.freebsd.org/src/commit/?id=407c34
On Mon, Mar 07, 2022 at 02:46:09PM +0100, Ronald Klop wrote:
> Dear Mark Johnston,
>
> I did some binary search in the kernels and came to the conclusion that
> https://cgit.freebsd.org/src/commit/?id=1517b8d5a7f58897200497811de1b18809c07d3e
> still works and
> https://cgit.freebsd.org/src/comm
> On 7 Mar 2022, at 15:13, Mark Johnston wrote:
> ...
> A (the?) problem is that the compiler is treating "pc" as an alias
> for x18, but the rmlock code assumes that the pcpu pointer is loaded
> once, as it dereferences "pc" outside of the critical section. On
> arm64, if a context switch occur
On Mon, Mar 07, 2022 at 04:25:22PM +, Andrew Turner wrote:
>
> > On 7 Mar 2022, at 15:13, Mark Johnston wrote:
> > ...
> > A (the?) problem is that the compiler is treating "pc" as an alias
> > for x18, but the rmlock code assumes that the pcpu pointer is loaded
> > once, as it dereferences "
On 2022-Mar-7, at 08:45, Mark Johnston wrote:
> On Mon, Mar 07, 2022 at 04:25:22PM +, Andrew Turner wrote:
>>
>>> On 7 Mar 2022, at 15:13, Mark Johnston wrote:
>>> ...
>>> A (the?) problem is that the compiler is treating "pc" as an alias
>>> for x18, but the rmlock code assumes that the
On Mon, Mar 07, 2022 at 10:03:51AM -0800, Mark Millard wrote:
>
>
> On 2022-Mar-7, at 08:45, Mark Johnston wrote:
>
> > On Mon, Mar 07, 2022 at 04:25:22PM +, Andrew Turner wrote:
> >>
> >>> On 7 Mar 2022, at 15:13, Mark Johnston wrote:
> >>> ...
> >>> A (the?) problem is that the compiler
On 04/03/2022 15:36, Johan Hendriks wrote:
Hello all, i use jails for some testing, but i can not seem to make it
stable.
I use vnet jails with a bridge but when i put some load on it, some
jails loose there network connectivity.
My setup is as follows, haproxy internal IP 10.233.185.20 usin
Van: Mark Johnston
Datum: maandag, 7 maart 2022 16:13
Aan: Ronald Klop
CC: bob prohaska , Mark Millard ,
freebsd-...@freebsd.org, freebsd-current
Onderwerp: Re: panic: data abort in critical section or under mutex (was: Re:
panic: Unknown kernel exception 0 esr_el1 200 (on 14-CURRENT/aar
On 2022-Mar-7, at 12:54, Ronald Klop wrote:
> Van: Mark Johnston
> Datum: maandag, 7 maart 2022 16:13
> Aan: Ronald Klop
> CC: bob prohaska , Mark Millard ,
> freebsd-...@freebsd.org, freebsd-current
> Onderwerp: Re: panic: data abort in critical section or under mutex (was: Re:
> panic:
On Mon, Mar 07, 2022 at 09:54:26PM +0100, Ronald Klop wrote:
>
> Van: Mark Johnston
> Datum: maandag, 7 maart 2022 16:13
> Aan: Ronald Klop
> CC: bob prohaska , Mark Millard ,
> freebsd-...@freebsd.org, freebsd-current
> > I haven't been able to reproduce any crashes running poudriere in an
>
14 matches
Mail list logo