Re: iflib/bridge kernel panic

[Alexander Leidinger]

Quoting Kristof Provost <k...@freebsd.org> (from Tue, 29 Sep 2020 23:20:44 +0200):

On 28 Sep 2020, at 16:44, Alexander Leidinger wrote:

Quoting Kristof Provost <k...@freebsd.org> (from Mon, 28 Sep 2020 13:53:16 +0200):

On 28 Sep 2020, at 12:45, Alexander Leidinger wrote:

Quoting Kristof Provost <k...@freebsd.org> (from Sun, 27 Sep 2020 17:51:32 +0200):

Here’s an early version of a task queue based approach: http://people.freebsd.org/~kp/0001-bridge-Cope-with-if_ioctl-s-that-sleep.patch

That still needs to be cleaned up, but this should resolve the sleep issue and the LOR.

Bridge setup:
  - member jail A
  - member jail B
  - member external_if of host

There are some issues... seems like inside a jail I can't ping systems outside of the hardware. If I ping the router from the host, it works. If I ping from one jail to another, it works. If I ping from the jail to the IP of the external_if, it works. If I ping from a jail to the router, I do not get a response.

Can you check for 'failed ifpromisc' error messages in dmesg? And verify that all bridge member interfaces are in promiscuous mode?

I have a panic for you...:

- tcpdump was running on the external interface

- startup still in progress = 22 jails in startup, somewhere after a few jails started the panic happened - a ping to a jail IP from another system was running, the first ping went through, then it paniced First regarding your questions about promisc mode: no error, but the promisc mode is directly disabled again on all interfaces.

I think I see why you had issues with the promiscuous setting. I’ve updated the patch to be even more horrific than it was before.

Hmmm.... same behavior as before.


# md5 0001-bridge-Cope-with-if_ioctl-s-that-sleep.patch

I haven't kept the old version of the patch, so I can't compare if I somehow downloaded the old version again, or if I got the updated one... MD5 (0001-bridge-Cope-with-if_ioctl-s-that-sleep.patch) = 9f107739e29fad5c9bb5e75e2dae7bcc

I can’t explain the panic, and the backtrace also doesn’t appear to be directly related to this patch. Not sure what’s going on with that.

Bye,
Alexander.


--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netch...@freebsd.org  : PGP 0x8F31830F9F2772BF

Then let's hope for now it is some kind of defect which is not showing up when it works as it should... we can have a look at it again in case it reproduces with the final patch.

pgpXvB8oyrPbh.pgp
Description: Digitale PGP-Signatur