On Sun, Apr 10 2022, Jeremie Courreges-Anglas wrote:
> On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote:
>> riscv64.ports was running dpb(1) with two other members in the build
>> cluster. A few minutes ago I found it in ddb(4). The report is short,
>> sadly, as the machine doesn't return
On Sun, Apr 10 2022, Jeremie Courreges-Anglas wrote:
> On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote:
>> riscv64.ports was running dpb(1) with two other members in the build
>> cluster. A few minutes ago I found it in ddb(4). The report is short,
>> sadly, as the machine doesn't return
On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote:
> riscv64.ports was running dpb(1) with two other members in the build
> cluster. A few minutes ago I found it in ddb(4). The report is short,
> sadly, as the machine doesn't return from the 'bt' command.
>
> The machine is acting both as an
> From: Jeremie Courreges-Anglas
> Date: Tue, 14 Dec 2021 13:29:11 +0100
>
> On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote:
> > riscv64.ports was running dpb(1) with two other members in the build
> > cluster. A few minutes ago I found it in ddb(4). The report is short,
> > sadly, as
On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote:
> riscv64.ports was running dpb(1) with two other members in the build
> cluster. A few minutes ago I found it in ddb(4). The report is short,
> sadly, as the machine doesn't return from the 'bt' command.
>
> The machine is acting both as an
On Mon, Nov 01 2021, Jeremie Courreges-Anglas wrote:
> On Mon, Nov 01 2021, Jeremie Courreges-Anglas wrote:
>> On Mon, Nov 01 2021, Martin Pieuchot wrote:
>>> On 31/10/21(Sun) 15:57, Jeremie Courreges-Anglas wrote:
On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote:
> riscv64.ports
On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote:
> riscv64.ports was running dpb(1) with two other members in the build
> cluster. A few minutes ago I found it in ddb(4). The report is short,
> sadly, as the machine doesn't return from the 'bt' command.
>
> The machine is acting both as an
On Sun, Oct 31 2021, Jeremie Courreges-Anglas wrote:
> On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote:
>> riscv64.ports was running dpb(1) with two other members in the build
>> cluster. A few minutes ago I found it in ddb(4). The report is short,
>> sadly, as the machine doesn't return
On 2021-11-01 17:24 +01, Jeremie Courreges-Anglas wrote:
> That was a bit premature, I finally managed to remotely connect to the
> machine. No idea why I couldn't connect to it for so long. Either
> a problem with the provider/router, or something wrong regarding
> riscv64, slaacd and the
On Mon, Nov 01 2021, Jeremie Courreges-Anglas wrote:
> On Mon, Nov 01 2021, Martin Pieuchot wrote:
>> On 31/10/21(Sun) 15:57, Jeremie Courreges-Anglas wrote:
>>> On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote:
>>> > riscv64.ports was running dpb(1) with two other members in the build
>>> >
We've been here before:
The problem is not related to KERNEL_LOCK around uvm_fault.
Jeremie Courreges-Anglas wrote:
> On Mon, Nov 01 2021, Martin Pieuchot wrote:
> > On 31/10/21(Sun) 15:57, Jeremie Courreges-Anglas wrote:
> >> On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote:
> >> >
Jeremie Courreges-Anglas wrote:
> Since I haven't mentioned it in this thread, clang crashes with SIGSEGV
> often when building ports. For the two first published bulk builds
> I just restarted the failed ports.
Some kernels do this. Other relinks don't.
On Mon, Nov 01 2021, Martin Pieuchot wrote:
> On 31/10/21(Sun) 15:57, Jeremie Courreges-Anglas wrote:
>> On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote:
>> > riscv64.ports was running dpb(1) with two other members in the build
>> > cluster. A few minutes ago I found it in ddb(4). The
On 31/10/21(Sun) 15:57, Jeremie Courreges-Anglas wrote:
> On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote:
> > riscv64.ports was running dpb(1) with two other members in the build
> > cluster. A few minutes ago I found it in ddb(4). The report is short,
> > sadly, as the machine doesn't
On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote:
> riscv64.ports was running dpb(1) with two other members in the build
> cluster. A few minutes ago I found it in ddb(4). The report is short,
> sadly, as the machine doesn't return from the 'bt' command.
>
> The machine is acting both as an
On Wed, Oct 20 2021, Jeremie Courreges-Anglas wrote:
[...]
> The machine is waiting in ddb(4). In the past panics, I didn't get
> control back after typing a ddb command, better choose wisely. ;)
Here's a nicer looking trace, I lost control after that command.
ddb{3}> show panic
*cpu3: Fatal
On Wed, Oct 20 2021, Jeremie Courreges-Anglas wrote:
> On Fri, Oct 08 2021, Mark Kettenis wrote:
>>> From: Jeremie Courreges-Anglas
>>> Date: Fri, 08 Oct 2021 18:19:47 +0200
>>>
>>> riscv64.ports was running dpb(1) with two other members in the build
>>> cluster. A few minutes ago I found it
On Fri, Oct 08 2021, Mark Kettenis wrote:
>> From: Jeremie Courreges-Anglas
>> Date: Fri, 08 Oct 2021 18:19:47 +0200
>>
>> riscv64.ports was running dpb(1) with two other members in the build
>> cluster. A few minutes ago I found it in ddb(4). The report is short,
>> sadly, as the machine
> From: Jeremie Courreges-Anglas
> Date: Fri, 08 Oct 2021 18:19:47 +0200
>
> riscv64.ports was running dpb(1) with two other members in the build
> cluster. A few minutes ago I found it in ddb(4). The report is short,
> sadly, as the machine doesn't return from the 'bt' command.
>
> The
riscv64.ports was running dpb(1) with two other members in the build
cluster. A few minutes ago I found it in ddb(4). The report is short,
sadly, as the machine doesn't return from the 'bt' command.
The machine is acting both as an NFS server and and NFS client.
OpenBSD/riscv64
20 matches
Mail list logo
