Re: iflib/bridge kernel panic

From: Alexander Leidinger <Alexander_at_leidinger.net>
Date: Wed, 30 Sep 2020 13:52:25 +0200
Quoting Kristof Provost <kp_at_freebsd.org> (from Tue, 29 Sep 2020  
23:20:44 +0200):

> On 28 Sep 2020, at 16:44, Alexander Leidinger wrote:
>
>> Quoting Kristof Provost <kp_at_freebsd.org> (from Mon, 28 Sep 2020  
>> 13:53:16 +0200):
>>
>>> On 28 Sep 2020, at 12:45, Alexander Leidinger wrote:
>>>> Quoting Kristof Provost <kp_at_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.
>>>>
>>>> There are some issues... seems like inside a jail I can't ping  
>>>> systems outside of the hardware.
>>>>
>>>> Bridge setup:
>>>>   - member jail A
>>>>   - member jail B
>>>>   - member external_if of host
>>>>
>>>> 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...:
>> - startup still in progress = 22 jails in startup, somewhere after  
>> a few jails started the panic happened
>> - tcpdump was running on the external interface
>> - 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.
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
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.

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.

Bye,
Alexander.


-- 
http://www.Leidinger.net Alexander_at_Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild_at_FreeBSD.org  : PGP 0x8F31830F9F2772BF

Received on Wed Sep 30 2020 - 09:52:56 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:25 UTC