On 29.6.2021. 23:05, Alexander Bluhm wrote:
> On Tue, Jun 29, 2021 at 10:39:14PM +0200, Hrvoje Popovski wrote:
>> with this diff without any traffic through aggr if i destroy aggr
>> interface i'm getting log below ... log can't be reproduced after first
>> destroy.. you need to reboot box and
On Tue, Jun 29, 2021 at 10:39:14PM +0200, Hrvoje Popovski wrote:
> with this diff without any traffic through aggr if i destroy aggr
> interface i'm getting log below ... log can't be reproduced after first
> destroy.. you need to reboot box and then destroy aggr ...
> i can't reproduce it with
On 29.6.2021. 19:19, Alexander Bluhm wrote:
> So what to do with this diff?
>
> - OK to commit?
> - Test it in snaps?
> - Call for testers?
>
> I it would be interesting if the kernel is stable when trunk or
> aggr interfaces are created or destroyed while the machine is under
> network load.
On Fri, Jun 18, 2021 at 11:32:59PM +0300, Vitaliy Makkoveev wrote:
> > I would give the diff below a try. Perhaps in snaps?
>
> Yes please. splx(9) logic should go away at least from this layer.
So what to do with this diff?
- OK to commit?
- Test it in snaps?
- Call for testers?
I it would
On Fri, Jun 18, 2021 at 07:18:53PM +0200, Alexander Bluhm wrote:
> On Thu, Jun 17, 2021 at 12:27:42PM +0300, Vitaliy Makkoveev wrote:
> > > Is this the correct version of the diff? Not tested yet.
>
> It survived a full regress run.
>
> > Hypothetically we could have the driver for the old NIC
On Thu, Jun 17, 2021 at 12:27:42PM +0300, Vitaliy Makkoveev wrote:
> > Is this the correct version of the diff? Not tested yet.
It survived a full regress run.
> Hypothetically we could have the driver for the old NIC which relies
> on disabled interrupts on this ioctl() sequence.
ifioctl()
On Thu, Jun 17, 2021 at 02:03:03AM +0200, Alexander Bluhm wrote:
> Thanks dlg@ for the hint with the ixl(4) fixes in current. I will
> try so solve my 6.6 problem with that.
>
> On Wed, Jun 16, 2021 at 10:19:03AM +0200, Martin Pieuchot wrote:
> > The diff discussed in this thread reduces the
Thanks dlg@ for the hint with the ixl(4) fixes in current. I will
try so solve my 6.6 problem with that.
On Wed, Jun 16, 2021 at 10:19:03AM +0200, Martin Pieuchot wrote:
> The diff discussed in this thread reduces the scope of the splnet/splx()
> dance to only surround the modification of
On 16/06/21(Wed) 14:26, David Gwynne wrote:
>
>
> > On 16 Jun 2021, at 00:39, Martin Pieuchot wrote:
> >
> > On 15/06/21(Tue) 22:52, David Gwynne wrote:
> >> On Mon, Jun 14, 2021 at 10:07:58AM +0200, Martin Pieuchot wrote:
> >>> On 10/06/21(Thu) 19:17, Alexander Bluhm wrote:
> >> [...]
>
> On 16 Jun 2021, at 00:39, Martin Pieuchot wrote:
>
> On 15/06/21(Tue) 22:52, David Gwynne wrote:
>> On Mon, Jun 14, 2021 at 10:07:58AM +0200, Martin Pieuchot wrote:
>>> On 10/06/21(Thu) 19:17, Alexander Bluhm wrote:
>> [...]
The in6_ functions need netlock. And driver SIOCSIFFLAGS
On 15/06/21(Tue) 22:52, David Gwynne wrote:
> On Mon, Jun 14, 2021 at 10:07:58AM +0200, Martin Pieuchot wrote:
> > On 10/06/21(Thu) 19:17, Alexander Bluhm wrote:
> [...]
> > > The in6_ functions need netlock. And driver SIOCSIFFLAGS ioctl
> > > must not have splnet().
> >
> > Why not? This is
On Mon, Jun 14, 2021 at 10:07:58AM +0200, Martin Pieuchot wrote:
> On 10/06/21(Thu) 19:17, Alexander Bluhm wrote:
> > Hi,
> >
> > I have seen this crash trace on a 6.6 based system, but I think the
> > bug exists still in -current. It happened when an ixl(4) interface
> > was removed from
On 10/06/21(Thu) 19:17, Alexander Bluhm wrote:
> Hi,
>
> I have seen this crash trace on a 6.6 based system, but I think the
> bug exists still in -current. It happened when an ixl(4) interface
> was removed from trunk(4).
>
> uvm_fault(0xfd8739dc6558, 0x0, 0, 1) -> e
> fatal page fault in
Is it expected interrupt handlers modify ifp->if_flags?
> On 10 Jun 2021, at 20:17, Alexander Bluhm wrote:
>
> Hi,
>
> I have seen this crash trace on a 6.6 based system, but I think the
> bug exists still in -current. It happened when an ixl(4) interface
> was removed from trunk(4).
>
>
Hi,
I have seen this crash trace on a 6.6 based system, but I think the
bug exists still in -current. It happened when an ixl(4) interface
was removed from trunk(4).
uvm_fault(0xfd8739dc6558, 0x0, 0, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 rip 81012a86 cs 8
15 matches
Mail list logo
