[MacPorts] #63650: Regression in glib2 after update to 2.62 version with qemu tap-bridge networking

MacPorts noreply at macports.org
Wed Oct 20 03:31:38 UTC 2021


#63650: Regression in glib2 after update to 2.62 version with qemu tap-bridge
networking
-----------------------+---------------------------------------------------
  Reporter:  andriytk  |      Owner:  (none)
      Type:  defect    |     Status:  new
  Priority:  Normal    |  Milestone:
 Component:  ports     |    Version:  2.7.1
Resolution:            |   Keywords:  qemu tap bridge networking regression
      Port:  glibc2    |
-----------------------+---------------------------------------------------
Description changed by andriytk:

Old description:

> After recent update from glib2 2.58.3_1 to 2.62.6_2 - QEMU tap-bridge
> networking stopped working: DHCP requests and replies from guest VM are
> seen on bridge0 interface, but on tap0 interface there are no replies
> (only the requests).
>
> The problem was reported also here -
> https://forum.osdev.org/viewtopic.php?f=1&t=39828.
>
> Tried with qemu-6.1 and 5.2 versions: in both cases it works fine with
> glib2 @2.58.3_1 (and required libffi @3.3_1), while it fails with glib2
> @2.62.6_2 (and required libffi @3.4.2_2).
>
> As suggested at
> https://forum.osdev.org/viewtopic.php?p=316408&sid=427623ba50fe49f3c5267a45f83fb1da#p316408
> the problem might be related to polling the device.
>
> Also, I noticed that qemu process always consumes 100% CPU even when the
> quest VM is idle. (Which supports the idea about some problem with
> polling the device.) Again, this is not observed with the previous glibc2
> version 2.58.3_1.
>
> See more details here on how to reproduce the problem -
> https://gist.github.com/andriytk/bd3def8c30cbd474490280436c779027.

New description:

 After recent update from glib2 2.58.3_1 to 2.62.6_2 - QEMU tap-bridge
 networking stopped working: DHCP requests and replies from guest VM are
 seen on bridge0 interface, but on tap0 interface there are no replies
 (only the requests).

 The problem was reported also here -
 https://forum.osdev.org/viewtopic.php?f=1&t=39828.

 Tried with qemu-6.1 and 5.2 versions: in both cases it works fine with
 glib2 @2.58.3_1 (plus required libffi @3.3_1), and fails with glib2
 @2.62.6_2 (plus required libffi @3.4.2_2).

 As suggested at
 https://forum.osdev.org/viewtopic.php?p=316408&sid=427623ba50fe49f3c5267a45f83fb1da#p316408
 the problem might be related to polling the device.

 Also, I noticed that qemu process always consumes 100% CPU even when the
 quest VM is idle. (Which supports the idea about some problem with polling
 the device.) Again, this is not observed with the previous glibc2 version
 2.58.3_1.

 See more details here on how to reproduce the problem -
 https://gist.github.com/andriytk/bd3def8c30cbd474490280436c779027.

--

-- 
Ticket URL: <https://trac.macports.org/ticket/63650#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list