Hi Stuart,
Yes, that'll be next move. I'll try it when I get a chance and revert
with results.
However, I thought I'd refrain from immediately doing such just in
case someone on the mailing list suggested that I carry out more
tests, etc. Then again, given I'm running everything off USB drives on
I would try updating to a snapshot to see if it helps the axen errors/panic.
I don't think "boot dump" is possible with USB storage.
--
Sent from a phone, apologies for poor formatting.
On 9 September 2020 05:56:33 OpenBSD Bug Reporter
wrote:
Hello again,
By way of update, if the kernel p
On Sat, Sep 05, 2020 at 08:11:21AM +0200, Otto Moerbeek wrote:
> On Fri, Sep 04, 2020 at 11:17:40PM +0200, Christian Weisgerber wrote:
>
> > Otto Moerbeek:
> >
> > > This takes the observed issue into account,
> > -snip-
> >
> > This works for my test case of a single peer and the two scenarios
Hello again,
By way of update, if the kernel panic occurs as first described, boot
dump seems to cause the system to hang on the message 'syncing
disks...' and I have to carry out a hard reset. Not surprisingly, on
boot, savecore reports that there was no core dump.
> OpenBSD/arm64 (foo) (console
Hello again,
Not sure if this is at all related to my previous email. Despite the
same kernel panic message, this is first time I have seen trace
messages like this.
> OpenBSD/arm64 (foo) (console)
>
> login: panic: assertwaitok: non-zero mutex count: 1
> Stopped at 0xff800074f198:
Hello,
Recurring bug on OpenBSD 6.7-RELEASE which results in kernel panic.
Hardware
- RPI4
- axen USB ethernet, D-Link DUB-1312 (USB3.0 Gigabit Ethernet Adapter)
- USB storage devices (variety have been tried and bug continues)
Occurs at least once a day. Sometimes more. System is running
24/7.
I was chasing the problem in the wrong place. After more
testing it turned out that Linux has exactly the same problem.
That should probably be one of my early steps, to verify hands
on, does the problem affect any other operating systems.
I found following GitHub issue:
https://github.co
Anyone interested in this?
On 8/30/20, Soumendra Ganguly wrote:
> The while+sleep wait for child has now been replaced with
> sigemptyset+sigsuspend.
>
>
>
> --- src/usr.bin/script/script.c 2020-08-04 02:41:13.226129480 -0500
> +++ script.c 2020-08-30 19:59:40.852918727 -0500
> @@ -105,6 +
@janne ... thanks. that was it. I did manage to get pwd_mkdb to work. As an
aside the help could use some improvement; but it did work!!
Thanks
*--Richard Bucker *
On Tue, Sep 8, 2020 at 10:45 AM Janne Johansson wrote:
> Den tis 8 sep. 2020 kl 16:31 skrev Richard Bucker :
>
>> After reading
On Tue, Sep 08 2020, Richard Bucker wrote:
> After reading the refs on submitting bug reports I believe this is the
> correct way to present it as it's probably a design issue and may be
> subjective as I know I do not know the whole system. So I will generalize
> in the hopes that I'm wrong.
>
>
Den tis 8 sep. 2020 kl 16:31 skrev Richard Bucker :
> After reading the refs on submitting bug reports I believe this is the
> correct way to present it as it's probably a design issue and may be
> subjective as I know I do not know the whole system. So I will generalize
> in the hopes that I'm wr
After reading the refs on submitting bug reports I believe this is the
correct way to present it as it's probably a design issue and may be
subjective as I know I do not know the whole system. So I will generalize
in the hopes that I'm wrong.
Everything starts with "my application"...
- chroot("so
12 matches
Mail list logo
