I found one of my amd64 systems running -current, built on 12th of
August, has crashed as follows.
I am not sure if this is still relevant; please excuse the noise if
this has already been found and fixed.
kernel: protection fault trap, code=0
Stopped at rt_ifa_del+0x39:movb0x1be
On Tue, Aug 23, 2022 at 10:15:22AM +0200, Stefan Sperling wrote:
> I found one of my amd64 systems running -current, built on 12th of
> August, has crashed as follows.
>
> I am not sure if this is still relevant; please excuse the noise if
> this has already been found and fixed.
>
> kernel: prot
On Tue, Aug 23, 2022 at 10:15:22AM +0200, Stefan Sperling wrote:
> I found one of my amd64 systems running -current, built on 12th of
> August, has crashed as follows.
I there any chance that the kernel sources are between these commits?
August 12th does not fit exactly, do you remember when you d
On Tue, Aug 23, 2022 at 11:43:22AM +0200, Alexander Bluhm wrote:
> On Tue, Aug 23, 2022 at 10:15:22AM +0200, Stefan Sperling wrote:
> > I found one of my amd64 systems running -current, built on 12th of
> > August, has crashed as follows.
>
> I there any chance that the kernel sources are between
On Tue, Aug 23, 2022 at 12:23:05PM +0200, Stefan Sperling wrote:
> On Tue, Aug 23, 2022 at 11:43:22AM +0200, Alexander Bluhm wrote:
> > On Tue, Aug 23, 2022 at 10:15:22AM +0200, Stefan Sperling wrote:
> > > I found one of my amd64 systems running -current, built on 12th of
> > > August, has crashed
On Tue, Aug 23, 2022 at 02:16:27PM +0200, Alexander Bluhm wrote:
> On Tue, Aug 23, 2022 at 12:23:05PM +0200, Stefan Sperling wrote:
> > On Tue, Aug 23, 2022 at 11:43:22AM +0200, Alexander Bluhm wrote:
> > > On Tue, Aug 23, 2022 at 10:15:22AM +0200, Stefan Sperling wrote:
> > > > I found one of my a
On Tue, Aug 23, 2022 at 02:47:11PM +0200, Stefan Sperling wrote:
> ddb{2}> show struct ifaddr 0x804e9400
> struct ifaddr at 0x804e9400 (64 bytes) {ifa_addr = (struct sockaddr
> *)0
> xdeaf0009deafbead, ifa_dstaddr = (struct sockaddr *)0x20ef1a8af1d895de,
> ifa_net
> mask = (struct
On Wed, Aug 24, 2022 at 03:14:35PM +0200, Alexander Bluhm wrote:
> What are you doing with the machine? Forwarding, IPv6, Stress test?
> Do you have network interfaces with multiple network queues?
It is a build box, which also serves snapshots over http. I am the only
user of the httpd server so
Anyone willing to test or ok this?
I would like to get it in before kn@ bumps ports due to net/if_var.h
changes.
On Wed, Aug 24, 2022 at 03:14:35PM +0200, Alexander Bluhm wrote:
> On Tue, Aug 23, 2022 at 02:47:11PM +0200, Stefan Sperling wrote:
> > ddb{2}> show struct ifaddr 0x804e9400
>
> On 27 Aug 2022, at 00:04, Alexander Bluhm wrote:
>
> Anyone willing to test or ok this?
>
This fixes weird `ifa’ refcounting. I like this.
Could the ifaref() and ifafree() names use the same notation? Like
ifaref() and ifarele() or ifaget() and ifafree() or something else?
> I would like t
On Sat, Aug 27, 2022 at 03:14:15AM +0300, Vitaliy Makkoveev wrote:
> > On 27 Aug 2022, at 00:04, Alexander Bluhm wrote:
> >
> > Anyone willing to test or ok this?
> >
>
> This fixes weird `ifa??? refcounting. I like this.
>
> Could the ifaref() and ifafree() names use the same notation? Like
>
> On 27 Aug 2022, at 22:03, Alexander Bluhm wrote:
>
> On Sat, Aug 27, 2022 at 03:14:15AM +0300, Vitaliy Makkoveev wrote:
>>> On 27 Aug 2022, at 00:04, Alexander Bluhm wrote:
>>>
>>> Anyone willing to test or ok this?
>>>
>>
>> This fixes weird `ifa??? refcounting. I like this.
>>
>> Could t
On Sat, Aug 27, 2022 at 11:32:24PM +0300, Vitaliy Makkoveev wrote:
> > On 27 Aug 2022, at 22:03, Alexander Bluhm wrote:
> >
> > On Sat, Aug 27, 2022 at 03:14:15AM +0300, Vitaliy Makkoveev wrote:
> >>> On 27 Aug 2022, at 00:04, Alexander Bluhm wrote:
> >>>
> >>> Anyone willing to test or ok this
On Sun, Sep 04, 2022 at 08:53:45AM +0200, Stefan Sperling wrote:
> On Sat, Aug 27, 2022 at 11:32:24PM +0300, Vitaliy Makkoveev wrote:
> > > On 27 Aug 2022, at 22:03, Alexander Bluhm wrote:
> > >
> > > On Sat, Aug 27, 2022 at 03:14:15AM +0300, Vitaliy Makkoveev wrote:
> > >>> On 27 Aug 2022, at 00
> On 4 Sep 2022, at 12:30, Klemens Nanni wrote:
>
>> The diff has been committed but the problem remains:
>>
>> OpenBSD 7.2-beta (GENERIC.MP) #2: Thu Sep 1 18:54:34 CEST 2022
>>
>>s...@bev.stsp.name:/usr/src/sys/arch/am
> On 4 Sep 2022, at 16:29, Vitaliy Makkoveev wrote:
>
>> On 4 Sep 2022, at 12:30, Klemens Nanni wrote:
>>
>>> The diff has been committed but the problem remains:
>>>
>>> OpenBSD 7.2-beta (GENERIC.MP) #2: Thu Sep 1 18:54:34 CEST 2022
>>>
On Sun, Sep 04, 2022 at 08:53:45AM +0200, Stefan Sperling wrote:
> On Sat, Aug 27, 2022 at 11:32:24PM +0300, Vitaliy Makkoveev wrote:
> > > On 27 Aug 2022, at 22:03, Alexander Bluhm wrote:
> > >
> > > On Sat, Aug 27, 2022 at 03:14:15AM +0300, Vitaliy Makkoveev wrote:
> > >>> On 27 Aug 2022, at 00
On Sun, Sep 04, 2022 at 05:42:14PM +0300, Vitaliy Makkoveev wrote:
> Not for commit, just for collect assertions. Netlock assertions doen't
> provide panics.
Better use NET_ASSERT_LOCKED_EXCLUSIVE() ?
But maybe nd6 uses a combination of shared netlock and kernel lock.
Is it possible that we slee
On Sun, Sep 04, 2022 at 06:02:09PM +0200, Alexander Bluhm wrote:
> On Sun, Sep 04, 2022 at 05:42:14PM +0300, Vitaliy Makkoveev wrote:
> > Not for commit, just for collect assertions. Netlock assertions doen't
> > provide panics.
>
> Better use NET_ASSERT_LOCKED_EXCLUSIVE() ?
>
> But maybe nd6 use
On Sun, Sep 04, 2022 at 07:34:04PM +0300, Vitaliy Makkoveev wrote:
> I suspect missing netlock in the config path or within timeout handler,
> but exclusive netlock assertion makes sense.
>
> Also, we could have "double protection" here, like we have for
> `if_list'. I mean we hold both kernel and
I hit the same issue on a 7.2-RELEASE system, which was idle and had
roughly 3 weeks of uptime.
Stopped at rt_ifa_del+0x39: movb 0x1b6(%rax),%bl
Same backtrace as in parent message.
The system is virtualized on QEMU/KVM 7.0 on Linux x86_64, has networking
over a bridge where radvd 2.19 announce
On Tue, Nov 15, 2022 at 03:07:05PM +0100, Leah Neukirchen wrote:
>
> I hit the same issue on a 7.2-RELEASE system, which was idle and had
> roughly 3 weeks of uptime.
>
> Stopped at rt_ifa_del+0x39: movb 0x1b6(%rax),%bl
> Same backtrace as in parent message.
>
> The system is virtualized on QEMU
On Tue, Nov 15, 2022 at 06:50:50PM +0100, Stefan Sperling wrote:
> On Tue, Nov 15, 2022 at 03:07:05PM +0100, Leah Neukirchen wrote:
> >
> > I hit the same issue on a 7.2-RELEASE system, which was idle and had
> > roughly 3 weeks of uptime.
> >
> > Stopped at rt_ifa_del+0x39: movb 0x1b6(%rax),%bl
>Synopsis: protection fault trap in rt_ifa_del with vio(4)
>Category: kernel
>Environment:
System : OpenBSD 7.3
Details : OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT
2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/comp
This is a purely vio(4) specific XXXSMP bug, 7.1 (perhaps earlier) has it
already.
There are multiple possible crashes, with IPv4 alone as well.
The one reported seems most likely to trigger.
25 matches
Mail list logo