somewhat reproducable vimage panic

Bjoern A. Zeeb bzeeb-lists at
Thu Jul 23 19:26:50 UTC 2020

On 23 Jul 2020, at 9:02, Kristof Provost wrote:

> On 23 Jul 2020, at 11:00, Bjoern A. Zeeb wrote:
>> On 23 Jul 2020, at 8:09, Kristof Provost wrote:
>>> On 23 Jul 2020, at 9:19, Kristof Provost wrote:
>>>> On 23 Jul 2020, at 0:15, John-Mark Gurney wrote:
>>>>> So, it's pretty easy to trigger, just attach a couple USB ethernet
>>>>> adapters, in my case, they were ure, but likely any two spare 
>>>>> ethernet
>>>>> interfaces will work, and wire them back to back..
>>>> I’ve been able to trigger it using epair as well:
>>>> `sudo sh testinterfaces.txt epair0a epair0b`
>>>> I did have to comment out the waitcarrier() check.
>>> I’ve done a little bit of digging, and I think I’m starting to 
>>> see how this breaks.
>>> This always affects the jailed vlan interfaces. They’re getting 
>>> deleted, but the ifp doesn’t go away just yet because it’s still 
>>> in use by the multicast code.
>>> The multicast code does its cleanup in task queues,
>> Wow, did I miss that back then? Did I review a change and not notice? 
>> Sorry if that was the case.
>> Vnet teardown is blocking and forceful.
>> Doing deferred cleanup work isn’t a good idea at all.
>> I think that is the real problem here.
>> I’d rather have us fix this than putting more bandaids into the 
>> code.
> Yeah, agreed. I think hselasky has a better fix: 
> I just saw his e-mail in a different thread.

That’ll probably work;  still, the deferred teardown work seems wrong 
to me;  I haven’t investigated;  the patch kind-of says exactly that 
as well: if “wait until deferred stuff is done” is all we are doing, 
why can we not do it on the spot then?


More information about the freebsd-net mailing list