Re: panic after ifioctl/if_clone_destroy
Hans Petter Selasky wrote: > On 8/11/18 9:44 AM, Roman Bogorodskiy wrote: > >Hans Petter Selasky wrote: > > > >> On 08/06/18 21:43, Matthew Macy wrote: > >>> The struct thread is typesafe. The problem is that the link is no longer > >>> typesafe now that it’s not part of the thread. Thanks for pointing this > >>> out. I’ll commit a fix later today. > >>> > >> > >> Is there a patch yet? > >> > >> --HPS > >> > > > > This was committed in: > > > > https://svnweb.freebsd.org/changeset/base/337525 > > > > However, I've just updated to r337595, and it still panics. Not sure if > > that's related to the original issue though: > > > > (kgdb) #0 doadump (textdump=0) at pcpu.h:230 > > #1 0x8043ddfb in db_dump (dummy=, > > dummy2=, dummy3=, > > dummy4=) at /usr/src/sys/ddb/db_command.c:574 > > #2 0x8043dbc9 in db_command (cmd_table=) > > at /usr/src/sys/ddb/db_command.c:481 > > #3 0x8043d944 in db_command_loop () > > at /usr/src/sys/ddb/db_command.c:534 > > #4 0x80440b6f in db_trap (type=, > > code=) at /usr/src/sys/ddb/db_main.c:252 > > #5 0x80bdef83 in kdb_trap (type=9, code=0, tf= > out>) > > at /usr/src/sys/kern/subr_kdb.c:693 > > #6 0x8107aee1 in trap_fatal (frame=0xfe00760dc8a0, eva=0) > > at /usr/src/sys/amd64/amd64/trap.c:906 > > #7 0x8107a3bd in trap (frame=0xfe00760dc8a0) at counter.h:87 > > #8 0x81054d05 in calltrap () > > at /usr/src/sys/amd64/amd64/exception.S:232 > > #9 0x80ded513 in inp_gcmoptions (ctx=0xf80003079f20) > > at epoch_private.h:188 > > #10 0x80bd9cba in epoch_call_task (arg=) > > at /usr/src/sys/kern/subr_epoch.c:507 > > #11 0x80bdd0a9 in gtaskqueue_run_locked (queue=0xf800035be900) > > at /usr/src/sys/kern/subr_gtaskqueue.c:332 > > #12 0x80bdce28 in gtaskqueue_thread_loop (arg=) > > at /usr/src/sys/kern/subr_gtaskqueue.c:507 > > #13 0x80b530c4 in fork_exit ( > > callout=0x80bdcda0 , > > arg=0xfe00061a4038, frame=0xfe00760dcac0) > > at /usr/src/sys/kern/kern_fork.c:1057 > > #14 0x81055cde in fork_trampoline () > > at /usr/src/sys/amd64/amd64/exception.S:990 > > #15 0x in ?? () > > Current language: auto; currently minimal > > (kgdb) > > > > Full core.txt is here: > > https://people.freebsd.org/~novel/misc/core.20180811.txt > > > > Roman Bogorodskiy > > > > What is the full panic message? Are you loading // unloading any network > modules? > > --HPS Fatal trap 9: general protection fault while in kernel mode cpuid = 2; apic id = 04 instruction pointer = 0x20:0x80ded513 stack pointer = 0x28:0xfe00760dc960 frame pointer = 0x28:0xfe00760dc9a0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (softirq_2) (more details in https://people.freebsd.org/~novel/misc/core.20180811.txt) Panic happens right after boot. I do have: if_tap_load="YES" if_bridge_load="YES" in /boot/loader.conf. Just as before, panic happens after creating/renaming bridge and tap interfaces. Last few lines before panic (as could be seen in core.20180811.txt linked above): bridge0: Ethernet address: 02:af:41:48:c7:00 bridge0: changing name to 'virbr0' tap0: Ethernet address: 00:bd:95:08:f7:00 tap0: link state changed to UP tap0: changing name to 'virbr0-nic' virbr0-nic: promiscuous mode enabled virbr0: link state changed to UP virbr0-nic: link state changed to DOWN virbr0: link state changed to DOWN bridge0: Ethernet address: 02:af:41:48:c7:00 bridge0: changing name to 'virbr-hostnet' tap0: Ethernet address: 00:bd:e5:0b:f7:00 tap0: link state changed to UP tap0: changing name to 'virbr-honet-nic' virbr-honet-nic: promiscuous mode enabled virbr-hostnet: link state changed to UP Roman Bogorodskiy signature.asc Description: PGP signature
Re: panic after ifioctl/if_clone_destroy
On 8/11/18 9:44 AM, Roman Bogorodskiy wrote: Hans Petter Selasky wrote: On 08/06/18 21:43, Matthew Macy wrote: The struct thread is typesafe. The problem is that the link is no longer typesafe now that it’s not part of the thread. Thanks for pointing this out. I’ll commit a fix later today. Is there a patch yet? --HPS This was committed in: https://svnweb.freebsd.org/changeset/base/337525 However, I've just updated to r337595, and it still panics. Not sure if that's related to the original issue though: (kgdb) #0 doadump (textdump=0) at pcpu.h:230 #1 0x8043ddfb in db_dump (dummy=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:574 #2 0x8043dbc9 in db_command (cmd_table=) at /usr/src/sys/ddb/db_command.c:481 #3 0x8043d944 in db_command_loop () at /usr/src/sys/ddb/db_command.c:534 #4 0x80440b6f in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:252 #5 0x80bdef83 in kdb_trap (type=9, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:693 #6 0x8107aee1 in trap_fatal (frame=0xfe00760dc8a0, eva=0) at /usr/src/sys/amd64/amd64/trap.c:906 #7 0x8107a3bd in trap (frame=0xfe00760dc8a0) at counter.h:87 #8 0x81054d05 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #9 0x80ded513 in inp_gcmoptions (ctx=0xf80003079f20) at epoch_private.h:188 #10 0x80bd9cba in epoch_call_task (arg=) at /usr/src/sys/kern/subr_epoch.c:507 #11 0x80bdd0a9 in gtaskqueue_run_locked (queue=0xf800035be900) at /usr/src/sys/kern/subr_gtaskqueue.c:332 #12 0x80bdce28 in gtaskqueue_thread_loop (arg=) at /usr/src/sys/kern/subr_gtaskqueue.c:507 #13 0x80b530c4 in fork_exit ( callout=0x80bdcda0 , arg=0xfe00061a4038, frame=0xfe00760dcac0) at /usr/src/sys/kern/kern_fork.c:1057 #14 0x81055cde in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:990 #15 0x in ?? () Current language: auto; currently minimal (kgdb) Full core.txt is here: https://people.freebsd.org/~novel/misc/core.20180811.txt Roman Bogorodskiy What is the full panic message? Are you loading // unloading any network modules? --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic after ifioctl/if_clone_destroy
Hans Petter Selasky wrote: > On 08/06/18 21:43, Matthew Macy wrote: > > The struct thread is typesafe. The problem is that the link is no longer > > typesafe now that it’s not part of the thread. Thanks for pointing this > > out. I’ll commit a fix later today. > > > > Is there a patch yet? > > --HPS > This was committed in: https://svnweb.freebsd.org/changeset/base/337525 However, I've just updated to r337595, and it still panics. Not sure if that's related to the original issue though: (kgdb) #0 doadump (textdump=0) at pcpu.h:230 #1 0x8043ddfb in db_dump (dummy=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:574 #2 0x8043dbc9 in db_command (cmd_table=) at /usr/src/sys/ddb/db_command.c:481 #3 0x8043d944 in db_command_loop () at /usr/src/sys/ddb/db_command.c:534 #4 0x80440b6f in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:252 #5 0x80bdef83 in kdb_trap (type=9, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:693 #6 0x8107aee1 in trap_fatal (frame=0xfe00760dc8a0, eva=0) at /usr/src/sys/amd64/amd64/trap.c:906 #7 0x8107a3bd in trap (frame=0xfe00760dc8a0) at counter.h:87 #8 0x81054d05 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #9 0x80ded513 in inp_gcmoptions (ctx=0xf80003079f20) at epoch_private.h:188 #10 0x80bd9cba in epoch_call_task (arg=) at /usr/src/sys/kern/subr_epoch.c:507 #11 0x80bdd0a9 in gtaskqueue_run_locked (queue=0xf800035be900) at /usr/src/sys/kern/subr_gtaskqueue.c:332 #12 0x80bdce28 in gtaskqueue_thread_loop (arg=) at /usr/src/sys/kern/subr_gtaskqueue.c:507 #13 0x80b530c4 in fork_exit ( callout=0x80bdcda0 , arg=0xfe00061a4038, frame=0xfe00760dcac0) at /usr/src/sys/kern/kern_fork.c:1057 #14 0x81055cde in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:990 #15 0x in ?? () Current language: auto; currently minimal (kgdb) Full core.txt is here: https://people.freebsd.org/~novel/misc/core.20180811.txt Roman Bogorodskiy signature.asc Description: PGP signature
Re: panic after ifioctl/if_clone_destroy
On 08/06/18 21:43, Matthew Macy wrote: The struct thread is typesafe. The problem is that the link is no longer typesafe now that it’s not part of the thread. Thanks for pointing this out. I’ll commit a fix later today. Is there a patch yet? --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic after ifioctl/if_clone_destroy
The struct thread is typesafe. The problem is that the link is no longer
typesafe now that it’s not part of the thread. Thanks for pointing this
out. I’ll commit a fix later today.
-M
On Mon, Aug 6, 2018 at 02:39 Hans Petter Selasky wrote:
> Hi Matthew,
>
> On 08/06/18 10:02, Hans Petter Selasky wrote:
> > - if ((tdwait = TAILQ_FIRST(>er_tdlist)) != NULL &&
> > - TD_IS_RUNNING(tdwait->et_td)) {
>
> At least the TD_IS_RUNNING() check is invalid. The "tdwait" structure is
> in the control of the other CPU and "tdwait->et_td" might be invalid at
> any time, so accessing any members here is not a good idea.
>
> It is pretty clear that the epoch was exited during the loop:
>
> etd->et_td = (void*)0xDEADBEEF;
>
> fault virtual address = 0xdeadc2ff
> fault code = supervisor read data, page not present
>
>
> If you remove the TD_IS_RUNNING() check I'm not sure how useful this
> loop will be ...
>
> --HPS
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic after ifioctl/if_clone_destroy
Hans Petter Selasky wrote: > Hi Roman, > > Can you try the attached patch? > > --HPS Thanks for the patch, works fine so far. I'll give it more testing in the next few days. Roman Bogorodskiy signature.asc Description: PGP signature
Re: panic after ifioctl/if_clone_destroy
Hi Matthew,
On 08/06/18 10:02, Hans Petter Selasky wrote:
- if ((tdwait = TAILQ_FIRST(>er_tdlist)) != NULL &&
- TD_IS_RUNNING(tdwait->et_td)) {
At least the TD_IS_RUNNING() check is invalid. The "tdwait" structure is
in the control of the other CPU and "tdwait->et_td" might be invalid at
any time, so accessing any members here is not a good idea.
It is pretty clear that the epoch was exited during the loop:
etd->et_td = (void*)0xDEADBEEF;
fault virtual address = 0xdeadc2ff
fault code = supervisor read data, page not present
If you remove the TD_IS_RUNNING() check I'm not sure how useful this
loop will be ...
--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic after ifioctl/if_clone_destroy
Hi Roman,
Can you try the attached patch?
--HPS
Index: sys/kern/subr_epoch.c
===
--- sys/kern/subr_epoch.c (revision 336962)
+++ sys/kern/subr_epoch.c (working copy)
@@ -232,33 +232,14 @@
struct epoch_thread *tdwait;
struct turnstile *ts;
struct lock_object *lock;
- int spincount, gen;
int locksheld __unused;
record = __containerof(cr, struct epoch_record, er_record);
td = curthread;
locksheld = td->td_locks;
- spincount = 0;
counter_u64_add(block_count, 1);
if (record->er_cpuid != curcpu) {
/*
- * If the head of the list is running, we can wait for it
- * to remove itself from the list and thus save us the
- * overhead of a migration
- */
- if ((tdwait = TAILQ_FIRST(>er_tdlist)) != NULL &&
- TD_IS_RUNNING(tdwait->et_td)) {
- gen = record->er_gen;
- thread_unlock(td);
- do {
-cpu_spinwait();
- } while (tdwait == TAILQ_FIRST(>er_tdlist) &&
- gen == record->er_gen && TD_IS_RUNNING(tdwait->et_td) &&
- spincount++ < MAX_ADAPTIVE_SPIN);
- thread_lock(td);
- return;
- }
- /*
* Being on the same CPU as that of the record on which
* we need to wait allows us access to the thread
* list associated with that CPU. We can then examine the
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic after ifioctl/if_clone_destroy
Hi,
I think the problem is the thread pointed to by tdwait exited. I would
say it is not allowed to peek into the other records threads, because
they may change under the hood and are not protected by the current context.
if (record->er_cpuid != curcpu) {
This optimisation is invalid or needs to be revisited:
/*
* If the head of the list is running, we can wait for it
* to remove itself from the list and thus save us the
* overhead of a migration
*/
if ((tdwait = TAILQ_FIRST(>er_tdlist)) != NULL &&
TD_IS_RUNNING(tdwait->et_td)) {
gen = record->er_gen;
thread_unlock(td);
do {
cpu_spinwait();
} while (tdwait == TAILQ_FIRST(>er_tdlist) &&
gen == record->er_gen && TD_IS_RUNNING(tdwait->et_td)
&&
spincount++ < MAX_ADAPTIVE_SPIN);
thread_lock(td);
return;
}
--HPS
On 08/05/18 22:01, Matthew Macy wrote:
If you could give me a self-contained reproducer that would expedite a fix.
Thanks.
-M
On Sun, Aug 5, 2018 at 08:36 Roman Bogorodskiy wrote:
Running -CURRENT r336863 on amd64. Get the following panic right after
(or during) boot:
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 04
fault virtual address = 0xdeadc2ff
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x80bd7858
stack pointer = 0x28:0xfe008b445580
frame pointer = 0x28:0xfe008b4455c0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 903 (libvirtd)
Traceback is:
(kgdb) #0 doadump (textdump=0) at pcpu.h:230
#1 0x8043dc7b in db_dump (dummy=,
dummy2=, dummy3=,
dummy4=) at /usr/src/sys/ddb/db_command.c:574
#2 0x8043da49 in db_command (cmd_table=)
at /usr/src/sys/ddb/db_command.c:481
#3 0x8043d7c4 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:534
#4 0x804409ef in db_trap (type=,
code=) at /usr/src/sys/ddb/db_main.c:252
#5 0x80bdd513 in kdb_trap (type=12, code=0, tf=)
at /usr/src/sys/kern/subr_kdb.c:693
#6 0x810769f1 in trap_fatal (frame=0xfe008b4454c0,
eva=3735929599)
at /usr/src/sys/amd64/amd64/trap.c:884
#7 0x81076b12 in trap_pfault (frame=0xfe008b4454c0,
usermode=) at pcpu.h:230
#8 0x8107611a in trap (frame=0xfe008b4454c0)
at /usr/src/sys/amd64/amd64/trap.c:427
#9 0x810518ac in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:230
#10 0x80bd7858 in epoch_block_handler_preempt (
global=, cr=0xfe00760c3a00,
arg=) at /usr/src/sys/kern/subr_epoch.c:256
#11 0x803994fd in ck_epoch_synchronize_wait (
global=0xf800030c5680,
cb=0x80bd77a0 , ct=0x0)
at /usr/src/sys/contrib/ck/src/ck_epoch.c:407
#12 0x80bd7630 in epoch_wait_preempt (epoch=0xf800030c5680)
at /usr/src/sys/kern/subr_epoch.c:389
#13 0x80c983bf in if_delgroup (ifp=0xf80003aab800,
groupname=0xf80005ff5e00 "bridge") at /usr/src/sys/net/if.c:1514
#14 0x80c9f2b2 in if_clone_destroyif (ifc=0xf80005ff5e00,
ifp=0xf80003aab800) at /usr/src/sys/net/if_clone.c:325
#15 0x80c9f0d5 in if_clone_destroy (name=0xfe008b4458d0
"virbr0")
at /usr/src/sys/net/if_clone.c:288
#16 0x80c9a2c3 in ifioctl (so=0xf80007edca38, cmd=2149607801,
data=, td=)
at /usr/src/sys/net/if.c:3053
#17 0x80c04259 in kern_ioctl (td=0xf80007c1a580,
fd=, com=,
data=) at file.h:330
#18 0x80c03f2e in sys_ioctl (td=0xf80007c1a580,
uap=0xf80007c1a940) at /usr/src/sys/kern/sys_generic.c:712
#19 0x81077401 in amd64_syscall (td=0xf80007c1a580, traced=0)
at subr_syscall.c:135
#20 0x8105218d in fast_syscall_common ()
at /usr/src/sys/amd64/amd64/exception.S:500
#21 0x0008028f4c0a in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language: auto; currently minimal
(kgdb)
It looks like panic happens during network interfaces related
operations. Couple of dmesg lines before panic:
Aug 5 19:02:42 romashka rtsold[585]: interface
bridge0 removed
Aug 5 19:02:42 romashka kernel: bridge0: Ethernet address:
02:af:41:48:c7:00
Aug 5 19:02:42 romashka kernel: bridge0: changing name to 'virbr-ab'
Aug 5 19:02:42 romashka kernel: tap0: Ethernet address: 00:bd:8d:11:f7:00
Aug 5 19:02:42 romashka kernel: tap0: link state changed to UP
Aug 5 19:02:42 romashka kernel: tap0: changing name to 'virbr-ab-nic'
Aug
Re: panic after ifioctl/if_clone_destroy
If you could give me a self-contained reproducer that would expedite a fix. Thanks. -M On Sun, Aug 5, 2018 at 08:36 Roman Bogorodskiy wrote: > Running -CURRENT r336863 on amd64. Get the following panic right after > (or during) boot: > > Fatal trap 12: page fault while in kernel mode > cpuid = 2; apic id = 04 > fault virtual address = 0xdeadc2ff > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x80bd7858 > stack pointer = 0x28:0xfe008b445580 > frame pointer = 0x28:0xfe008b4455c0 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 903 (libvirtd) > > Traceback is: > > (kgdb) #0 doadump (textdump=0) at pcpu.h:230 > #1 0x8043dc7b in db_dump (dummy=, > dummy2=, dummy3=, > dummy4=) at /usr/src/sys/ddb/db_command.c:574 > #2 0x8043da49 in db_command (cmd_table=) > at /usr/src/sys/ddb/db_command.c:481 > #3 0x8043d7c4 in db_command_loop () > at /usr/src/sys/ddb/db_command.c:534 > #4 0x804409ef in db_trap (type=, > code=) at /usr/src/sys/ddb/db_main.c:252 > #5 0x80bdd513 in kdb_trap (type=12, code=0, tf= out>) > at /usr/src/sys/kern/subr_kdb.c:693 > #6 0x810769f1 in trap_fatal (frame=0xfe008b4454c0, > eva=3735929599) > at /usr/src/sys/amd64/amd64/trap.c:884 > #7 0x81076b12 in trap_pfault (frame=0xfe008b4454c0, > usermode=) at pcpu.h:230 > #8 0x8107611a in trap (frame=0xfe008b4454c0) > at /usr/src/sys/amd64/amd64/trap.c:427 > #9 0x810518ac in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:230 > #10 0x80bd7858 in epoch_block_handler_preempt ( > global=, cr=0xfe00760c3a00, > arg=) at /usr/src/sys/kern/subr_epoch.c:256 > #11 0x803994fd in ck_epoch_synchronize_wait ( > global=0xf800030c5680, > cb=0x80bd77a0 , ct=0x0) > at /usr/src/sys/contrib/ck/src/ck_epoch.c:407 > #12 0x80bd7630 in epoch_wait_preempt (epoch=0xf800030c5680) > at /usr/src/sys/kern/subr_epoch.c:389 > #13 0x80c983bf in if_delgroup (ifp=0xf80003aab800, > groupname=0xf80005ff5e00 "bridge") at /usr/src/sys/net/if.c:1514 > #14 0x80c9f2b2 in if_clone_destroyif (ifc=0xf80005ff5e00, > ifp=0xf80003aab800) at /usr/src/sys/net/if_clone.c:325 > #15 0x80c9f0d5 in if_clone_destroy (name=0xfe008b4458d0 > "virbr0") > at /usr/src/sys/net/if_clone.c:288 > #16 0x80c9a2c3 in ifioctl (so=0xf80007edca38, cmd=2149607801, > data=, td=) > at /usr/src/sys/net/if.c:3053 > #17 0x80c04259 in kern_ioctl (td=0xf80007c1a580, > fd=, com=, > data=) at file.h:330 > #18 0x80c03f2e in sys_ioctl (td=0xf80007c1a580, > uap=0xf80007c1a940) at /usr/src/sys/kern/sys_generic.c:712 > #19 0x81077401 in amd64_syscall (td=0xf80007c1a580, traced=0) > at subr_syscall.c:135 > #20 0x8105218d in fast_syscall_common () > at /usr/src/sys/amd64/amd64/exception.S:500 > #21 0x0008028f4c0a in ?? () > > > Previous frame inner to this frame (corrupt stack?) > > > Current language: auto; currently minimal > > > (kgdb) > > It looks like panic happens during network interfaces related > operations. Couple of dmesg lines before panic: > > Aug 5 19:02:42 romashka rtsold[585]: interface > bridge0 removed > Aug 5 19:02:42 romashka kernel: bridge0: Ethernet address: > 02:af:41:48:c7:00 > Aug 5 19:02:42 romashka kernel: bridge0: changing name to 'virbr-ab' > Aug 5 19:02:42 romashka kernel: tap0: Ethernet address: 00:bd:8d:11:f7:00 > Aug 5 19:02:42 romashka kernel: tap0: link state changed to UP > Aug 5 19:02:42 romashka kernel: tap0: changing name to 'virbr-ab-nic' > Aug 5 19:02:42 romashka kernel: virbr-ab-nic: promiscuous mode enabled > Aug 5 19:02:42 romashka kernel: virbr-ab: link state changed to UP > Aug 5 19:02:42 romashka rtsold[585]: interface > tap0 removed > Aug 5 19:02:43 romashka dnsmasq[1047]: setting --bind-interfaces option > because of OS limitations > Aug 5 19:02:43 romashka dnsmasq[1047]: warning: no upstream servers > configured > Aug 5 19:02:43 romashka kernel: virbr-ab-nic: link state changed to DOWN > Aug 5 19:02:43 romashka kernel: virbr-ab: link state changed to DOWN > Aug 5 19:02:43 romashka kernel: bridge1: Ethernet address: > 02:af:41:48:c7:01 > Aug 5 19:02:43 romashka kernel: bridge1: changing name to 'virbr0' > Aug 5 19:02:43 romashka rtsold[585]: interface > bridge1 removed > Aug 5 19:02:43 romashka kernel: tap1: Ethernet address: 00:bd:53:14:f7:01 > Aug 5 19:02:43 romashka kernel: tap1: link state changed to UP > Aug 5 19:02:43 romashka kernel: tap1: changing name to 'virbr0-nic' > Aug 5 19:02:43 romashka kernel: virbr0: link state changed to UP > Aug 5
