Intermittent Loss of hostapd/blue0

retiredipcop · 25 April 2020 23:21

My blue0 (hostapd) network drops occasionally, with no particular pattern. The only hint of a cause shows up in the logs, thus:

Apr 25 14:02:58 ipfire kernel: irq 11: nobody cared (try booting with the "irqpoll" option)
Apr 25 14:02:58 ipfire kernel: CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W  O    4.14.173-ipfire-pae #1
Apr 25 14:02:58 ipfire kernel: Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
Apr 25 14:02:58 ipfire kernel: Call Trace:
Apr 25 14:02:58 ipfire kernel:  <IRQ>
Apr 25 14:02:58 ipfire kernel:  dump_stack+0x60/0x88
Apr 25 14:02:58 ipfire kernel:  __report_bad_irq+0x38/0x9e
Apr 25 14:02:58 ipfire kernel:  ? handle_nested_irq+0xd0/0xd0
Apr 25 14:02:58 ipfire kernel:  note_interrupt.cold+0x9/0x59
Apr 25 14:02:58 ipfire kernel:  ? handle_nested_irq+0xd0/0xd0
Apr 25 14:02:58 ipfire kernel:  handle_irq_event_percpu+0x49/0x60
Apr 25 14:02:58 ipfire kernel:  handle_irq_event+0x27/0x40
Apr 25 14:02:58 ipfire kernel:  handle_level_irq+0x71/0xf0
Apr 25 14:02:58 ipfire kernel:  handle_irq+0x8d/0xb0
Apr 25 14:02:58 ipfire kernel:  </IRQ>
Apr 25 14:02:58 ipfire kernel:  <SOFTIRQ>
Apr 25 14:02:58 ipfire kernel:  do_IRQ+0x43/0xd0
Apr 25 14:02:58 ipfire kernel:  common_interrupt+0x3b/0x40
Apr 25 14:02:58 ipfire kernel: EIP: e1000_alloc_rx_buffers+0x329/0x440 [e1000]
Apr 25 14:02:58 ipfire kernel: EFLAGS: 00200286 CPU: 0
Apr 25 14:02:58 ipfire kernel: EAX: d0962818 EBX: d095c324 ECX: 00000000 EDX: 00000042
Apr 25 14:02:58 ipfire kernel: ESI: cd72a580 EDI: cddb1dc0 EBP: cf87bedc ESP: cf87beac
Apr 25 14:02:58 ipfire kernel:  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Apr 25 14:02:58 ipfire kernel:  ? e1000_alloc_jumbo_rx_buffers+0x230/0x230 [e1000]
Apr 25 14:02:58 ipfire kernel:  e1000_clean_rx_irq+0x312/0x490 [e1000]
Apr 25 14:02:58 ipfire kernel:  ? e1000_clean_jumbo_rx_irq+0x5e0/0x5e0 [e1000]
Apr 25 14:02:58 ipfire kernel:  e1000_clean+0x1f4/0x500 [e1000]
Apr 25 14:02:58 ipfire kernel:  net_rx_action+0x193/0x600
Apr 25 14:02:58 ipfire kernel:  __do_softirq+0xbc/0x275
Apr 25 14:02:58 ipfire kernel:  ? __irqentry_text_end+0x5/0x5
Apr 25 14:02:58 ipfire kernel:  call_on_stack+0x45/0x50
Apr 25 14:02:58 ipfire kernel:  </SOFTIRQ>
Apr 25 14:02:58 ipfire kernel:  ? irq_exit+0xc5/0xd0
Apr 25 14:02:58 ipfire kernel:  ? do_IRQ+0x7b/0xd0
Apr 25 14:02:58 ipfire kernel:  ? common_interrupt+0x3b/0x40
Apr 25 14:02:58 ipfire kernel:  ? __sched_text_end+0x1/0x1
Apr 25 14:02:58 ipfire kernel:  ? native_safe_halt+0xe/0x10
Apr 25 14:02:58 ipfire kernel:  ? default_idle+0x1c/0xf0
Apr 25 14:02:58 ipfire kernel:  ? arch_cpu_idle+0x12/0x20
Apr 25 14:02:58 ipfire kernel:  ? default_idle_call+0x1e/0x30
Apr 25 14:02:58 ipfire kernel:  ? do_idle+0x165/0x1b0
Apr 25 14:02:58 ipfire kernel:  ? cpu_startup_entry+0x55/0x60
Apr 25 14:02:58 ipfire kernel:  ? rest_init+0x88/0x8a
Apr 25 14:02:58 ipfire kernel:  ? start_kernel+0x4b8/0x4d0
Apr 25 14:02:58 ipfire kernel:  ? i386_start_kernel+0x62/0x78
Apr 25 14:02:58 ipfire kernel:  ? startup_32_smp+0x164/0x168
Apr 25 14:02:58 ipfire kernel: handlers:
Apr 25 14:02:58 ipfire kernel: [<c18c04c0>] ahci_single_level_irq_intr
Apr 25 14:02:58 ipfire kernel: [<c18d7350>] usb_hcd_irq
Apr 25 14:02:58 ipfire kernel: [<d0bff290>] snd_intel8x0_interrupt [snd_intel8x0]
Apr 25 14:02:58 ipfire kernel: [<d0b59820>] e1000_intr [e1000]
Apr 25 14:02:58 ipfire kernel: Disabling IRQ #11
Apr 25 14:03:04 ipfire kernel: xhci_hcd 0000:00:0c.0: xHCI host not responding to stop endpoint command.
Apr 25 14:03:04 ipfire kernel: xhci_hcd 0000:00:0c.0: xHCI host controller not responding, assume dead
Apr 25 14:03:04 ipfire kernel: xhci_hcd 0000:00:0c.0: HC died; cleaning up
Apr 25 14:03:04 ipfire kernel: rtl_usb: reg 0x608, usbctrl_vendorreq TimeOut! status:0xffffffed value=0xf000690e
Apr 25 14:03:04 ipfire kernel: rtl_usb: reg 0xc50, usbctrl_vendorreq TimeOut! status:0xffffffed value=0x69543424
Apr 25 14:03:04 ipfire kernel: rtl_usb: reg 0xc58, usbctrl_vendorreq TimeOut! status:0xffffffed value=0x69543424
Apr 25 14:03:04 ipfire kernel: rtl_usb: reg 0xda0, usbctrl_vendorreq TimeOut! status:0xffffffed value=0x12502f1
Apr 25 14:03:04 ipfire kernel: usb 1-1: USB disconnect, device number 2
Apr 25 14:03:04 ipfire kernel: usb 1-2: USB disconnect, device number 3
Apr 25 14:03:04 ipfire hostapd: blue0: STA e4:e1:30:09:dc:be MLME: MLME-DEAUTHENTICATE.indication(e4:e1:30:09:dc:be, 1)
Apr 25 14:03:04 ipfire hostapd: blue0: STA e4:e1:30:09:dc:be MLME: MLME-DELETEKEYS.request(e4:e1:30:09:dc:be)
Apr 25 14:03:04 ipfire dhcpd: receive_packet failed on blue0: Network is down
Apr 25 14:03:04 ipfire hostapd: blue0: STA d0:c5:d3:b2:91:4d MLME: MLME-DEAUTHENTICATE.indication(d0:c5:d3:b2:91:4d, 1)
Apr 25 14:03:04 ipfire hostapd: blue0: STA d0:c5:d3:b2:91:4d MLME: MLME-DELETEKEYS.request(d0:c5:d3:b2:91:4d)
Apr 25 14:03:06 ipfire ntpd[3372]: Deleting interface #5 blue0, 192.168.53.1#123, interface stats: received=0, sent=0, dropped=0, active_time=7450 secs

I wonder if this is related to the other bug I reported, 2062.

xperimental · 26 April 2020 04:43

Your Bug is your VM appliance. Nothing more to say.

retiredipcop · 26 April 2020 08:25

The “VM appliance” is Ipfire. I think you mean the virtualization environment?

The dismissive tone is unsettling.

xperimental · 26 April 2020 09:39

I think of VirtualBox or the system hardware. With the upcoming of Meltdown and co. I lost the track of changes for VT in existing hardware implementations. There have been also many changed within the IME.

In your case there are more than just 2 reasons possible:

BIOS bugs / outdated
Disabled VT techniques by BIOS, host OS or VirtualBOX
Disabled/removed VT techniques because of CPU vulnerabilities
Problems of your host OS with your hardware and/or drivers

And still: ipfire doesn’t like to be a VM

xperimental · 26 April 2020 09:41

There is nothing more to say.

pike_it · 27 April 2020 07:01

Yeah, sure.

retiredipcop · 27 April 2020 07:21

I’ve been running ipfire (and before that, ipcop) in a VM for as long as I’ve been using ipfire. I originally ran ipcop on an old Presario 386 for quite a few years before it burnt up. I moved it to another box, then finally to a VM around the time I switched to ipfire.

Ipcop/ipfire has been humming along in a VM for at least 10 years now.

Thanks to all those here who leave constructive and helpful, or at least neutral, suggestions.

pmueller · 2 May 2020 06:33

Hi,

first, please stick to facts!

Second:

I wonder if this is related to the other bug I reported, 2062.

At https://community.ipfire.org/, you open up a threat, not a bug. The latter ones are filed
and kept track of at https://bugzilla.ipfire.org/ (your login credentials work there as well);
please refer to wiki.ipfire.org - Bugzilla for further information about this.

Apr 25 14:03:04 ipfire kernel: xhci_hcd 0000:00:0c.0: xHCI host not responding to stop endpoint command.
Apr 25 14:03:04 ipfire kernel: xhci_hcd 0000:00:0c.0: xHCI host controller not responding, assume dead
Apr 25 14:03:04 ipfire kernel: xhci_hcd 0000:00:0c.0: HC died; cleaning up

Indeed, these look like coming from your host, but I am not sure. Could you please open a
bug at https://bugzilla.ipfire.org/ so we can keep track of this?

Thanks, and best regards,
Peter Müller

arne_f · 2 May 2020 07:25

I also suggest to reconfigure the NIC’s of the VM from e1000 to virtual nic’s this has not the Emulated IRQ overhead.

According fireinfo 26% of all installations running in VM’s

retiredipcop · 2 May 2020 07:41

Peter: First, I was addressing comments by an OP. Second, I did open a bug at 2062. It may be under a different ID, or maybe my bug matched 2062. I’ll try to be more consistent with my ID usage here.

Finally, I DO understand the difference between a bug and a threaD (typo? At first I thought you were telling me to file malware threats there).

As far as the way the word “host” is used in the context of xHCI, I believe (97% sure) that refers to the usb hub, which is virtualized in the guest. It has nothing to do with the system that is hosting the VM.

I’ll file a bug on this once I have acquired enough info about it. I am not sure if this is certainly a bug or not.

retiredipcop · 4 May 2020 04:11

Peter: My credentials don’t seem to work on the bug site. I tried an old login, but that might have been killed when you re-did the website a while back. I’d like to change my email address also. I don’t see a way to do that.

How can I create a new login on the bug site?