> On 9. Mar 2022, at 02:22, matthew green wrote:
>
> matthew green writes:
>> "J. Hannken-Illjes" writes:
>>> I'm now able to reproduce it here -- takes about six hours to trigger.
>>>
>>> I suppose vrelel() lost a check for new references with my last changes,
>>> currently testing the diff
matthew green writes:
> "J. Hannken-Illjes" writes:
> > I'm now able to reproduce it here -- takes about six hours to trigger.
> >
> > I suppose vrelel() lost a check for new references with my last changes,
> > currently testing the diff attached.
>
> well, this ran until i ran out of file
"J. Hannken-Illjes" writes:
> I'm now able to reproduce it here -- takes about six hours to trigger.
>
> I suppose vrelel() lost a check for new references with my last changes,
> currently testing the diff attached.
well, this ran until i ran out of file building the native gcc,
it had been
> On 8. Mar 2022, at 05:14, matthew green wrote:
>
> that's this:
>
> 175 vmcmd_map_pagedvn(struct lwp *l, struct exec_vmcmd *cmd)
> 176 {
> [ ... ]
> 181 vm_prot_t prot, maxprot;
> 182
> 183 KASSERT(vp->v_iflag & VI_TEXT);
>
> christos said this happened to him on a 8c/16t
that's this:
175 vmcmd_map_pagedvn(struct lwp *l, struct exec_vmcmd *cmd)
176 {
[ ... ]
181 vm_prot_t prot, maxprot;
182
183 KASSERT(vp->v_iflag & VI_TEXT);
christos said this happened to him on a 8c/16t 64GB machine, using
build.sh -j40, and i was able reproduce it on a 6c/12th