More on network issue "send queue timed out"

[Ulrich Windl]

Hi!

Today I was booting Qubes OS after having run Windows 10. I was unable
to get a network connection, even after booting several times.
The message in sys-net was the infamouse "send queue timed out" while
DCHP was repeatedly requesting a lease (but did not receive any response).

Eventually I unplugged the cable, let all the VMs start up and
stabilize, the plugged in the cable again, and I had networking!

I'm unsure which of the unusual messages I had saved are related to the
real problem. Anyway here are some:

First Xen hypervisor itself:
(XEN) Freed 316kB init memory
(XEN) Bogus DMIBAR 0xfed18001 on 0000:00:00.0
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:05:00.0] fault addr
c653f000, iommu reg = ffff82c000201000
(XEN) [VT-D]DMAR: reason 02 - Present bit in context entry is clear
(XEN) [VT-D]DMAR:[DMA Read] Request device [0000:05:00.0] fault addr
c653f000, iommu reg = ffff82c000201000
(XEN) [VT-D]DMAR: reason 02 - Present bit in context entry is clear
(XEN) [VT-D]DMAR:[DMA Write] Request device [0000:05:00.0] fault addr
c653f000, iommu reg = ffff82c000201000
(XEN) [VT-D]DMAR: reason 02 - Present bit in context entry is clear

Unsure which device this is related to, maybe Firewire?:
5:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire
II(M)] IEEE 1394 OHCI Controller (rev 46)

From sys-net:
CPU: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz (family: 0x6, model: 0x3c,
stepping: 0x3)
...
Performance Events: unsupported p6 CPU model 60 no PMU driver, software
events only.
Not enabling interrupt remapping due to skipped IO-APIC setup

The message above logs call traces in the journal, but due to missing
kernel symbols the call trace is undecodable:

...
Call Trace:
? 0xffffffff81a78e8f
? 0xffffffff81a675cd
? 0xffffffff81a78fdd
? 0xffffffff81a5ed95
? 0xffffffff81217a24
? 0xffffffff81217a29
? 0xffffffff814001b5
Code: c2 48 83 f8 ff 48 0f 45 c2 c3 48 c7 c0 a8 5a 80 81 c3 48 c7 06 ff
00 00 00 c3 48 89 f8 b9 00 04 00 00 48 89 f7 48 89 c6 f3 a5 c3 <0f> 0b
89 f8 c3 89 f8 c1 e8 18 c3 31 c0 c3 31 c0 c3 0f 0b c3 31

Then some more odd messages:
acb817a0-0010-49ef-96c1-86ccbedd84eb
[00:06.0] xen_pt_realize: Assigning real physical device 00:00.0 to
devfn 0x30
[00:06.0] xen_pt_register_regions: IO region 0 registered
(size=0x00000100 base_addr=0x0000d000 type: 0x1)
[00:06.0] xen_pt_register_regions: IO region 2 registered
(size=0x00001000 base_addr=0xf7d00000 type: 0x4)
[00:06.0] xen_pt_register_regions: IO region 4 registered
(size=0x00004000 base_addr=0xf0300000 type: 0x4)
{"execute": "device_add", "arguments": {"driver": "xen-pci-passthrough",
"id": "xen-pci-pt_0000-03-00.0", "hostaddr": "0000:00:00.00",
"machine_addr": "0000:03:00.0", "permissive": false}}
[00:06.0] xen_pt_config_reg_init: Offset 0x000e mismatch!
Emulated=0x0080, host=0x0000, syncing to 0x0000.
[00:06.0] xen_pt_config_reg_init: Offset 0x0010 mismatch!
Emulated=0x0000, host=0xd001, syncing to 0xd001.
[00:06.0] xen_pt_config_reg_init: Offset 0x0018 mismatch!
Emulated=0x0000, host=0xf7d00004, syncing to 0xf7d00004.
[00:06.0] xen_pt_config_reg_init: Offset 0x0020 mismatch!
Emulated=0x0000, host=0xf030000c, syncing to 0xf030000c.
[00:06.0] xen_pt_config_reg_init: Offset 0x0042 mismatch!
Emulated=0x0000, host=0x07c3, syncing to 0x0603.
[00:06.0] xen_pt_config_reg_init: Offset 0x00d2 mismatch!
Emulated=0x0000, host=0x8000, syncing to 0x8000.
[00:06.0] xen_pt_config_reg_init: Offset 0x0052 mismatch!
Emulated=0x0000, host=0x0080, syncing to 0x0080.
[00:06.0] xen_pt_config_reg_init: Offset 0x0074 mismatch!
Emulated=0x0000, host=0x5908cc0, syncing to 0x5908cc0.
[00:06.0] xen_pt_config_reg_init: Offset 0x007a mismatch!
Emulated=0x0000, host=0x0010, syncing to 0x0010.
[00:06.0] xen_pt_config_reg_init: Offset 0x0082 mismatch!
Emulated=0x0000, host=0x1011, syncing to 0x1011.
[00:06.0] xen_pt_pci_intx: intx=1
[00:06.0] xen_pt_realize: Real physical device 00:00.0 registered
successfully
{"return": {}}


Unfortunately it seems journal messages in sys-net do not survive reboots.

Regards,
Ulrich