Messages

Should be fixed with https://github.com/opnsense/core/commit/00afadefce308c2a701ad2c9d5baeacec668c136

# opnsense-patch 00afade

Hi,

Thanks for the report. FWIW it's likely this is only reproducible when the deployment type is set to "development" in System -> Settings -> Administration, otherwise these warnings should be silenced.

Hello,

Thanks, should be fixed with https://github.com/opnsense/core/commit/2c3ac5d69268f4bf066dddd74e481da840eceb84

# opnsense-patch 2c3ac5d

I tested this on all the Deciso appliance variants running the E810 with 10G-SR and 25G-SR fiber optics. All link and communicate just fine with the DDP package loaded. The link may take a few cycles to come up, but this shouldn't be a problem.

Reading all of the reports in here, as well as https://forum.opnsense.org/index.php?topic=52405 I'm seeing quite some variablity in reported firmware version and indeed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296989 also reports versions >= 4.60. The only report in the forum post concerning a DEC4280 was on a non-standard firmware version (DEC devices run NVM 4.30), which is not something that's supported.

You have to make your browser window smaller like it is on mobile devices to reproduce this scrolling issue. I had it also in Safari on my Mac but only when the browser window is small enought. I've experienced it at least for the new firewall rules list.

This was indeed the trigger, thanks for reporting.

It should be fixed with

# opnsense-patch https://github.com/opnsense/core/commit/6e3cda346c858d0b070b77439bdd322d6a0db7c1

Assuming the other patch Franco mentioned wasn't reverted.

Make sure the proposals are actually the same for IKE (the connection or phase 1). Seems like it fails there instead of your phase 2, which use a separate set of proposals.

Well, drivers don't log that much data in general. Another test kernel has been made available which includes disabling ASPM, a cleanup of some suspicious spots and more verbose logging (but not disruptive). If anyone is on version 26.1.x and wants to test:

# opnsense-update -zkr 26.1.11-igc2

and reboot.

Again, the timestamp of a failure and the relevant "System -> Log Files -> General" snippet of the same time is most relevant here.

Edit: kernel for 26.7 is up as well:

# opnsense-update -zkr 26.7-igc2

A kernel patch related to your issue has been developed, assuming you're on 26.1.11_6, you can install it with:

# opnsense-update -zkr 26.1.11-igc

and reboot.

Otherwise if you're on 26.7:

# opnsense-update -zkr 26.7-igc

Relevant events should be logged in System -> Log Files -> General. Can you share these here?

What's the status of 'igc' related changes in the kernel shipped with 26.7?  Do we still need to patch post upgrade?

The kernel patches have not been shipped. Neither patch confirmed or solved anything, there's also no custom kernel for these patches on the 26.7 ABI.

Unfortunately the -igc_aspm kernel didn't resolve my issue. It happened again this morning, and as usual bouncing the LAN interface with ifconfig down/up resolved it. There's nothing interesting in dmesg and the only recent entries in the syslog relate to a DHCP renewal for the WAN interface (which is not something I've seen in other instances).

One more thing to try before I'm going to suggest a more complicated troubleshooting setup to help classify the issue:

Disable flow control on all igc ports through System -> Settings -> Tunables. Tunable: "dev.igc.X.fc", Value: "0" (where X is the port). For 4 ports I'd expect 4 entries.

Intel seems to have "fixed" the hang problem by detecting it in the Linux driver and issuing a reset - FreeBSD has only now picked up that change in the OS driver (that was what my bug report was about).

"TX hangs" have been around forever, which is why watchdog timeouts have been baked into iflib from the get-go (but broke somewhere along the way 5 years ago, the logic wasn't missing), the same goes for the Linux driver - the reset logic has been in there since the first commit. Nothing special about it. However, it being broken definitely hinted at other platforms only reporting "micro freezes" instead of full freezes.

https://github.com/freebsd/freebsd-src/pull/2318

Is this patch included in OPNsense v26.7?

It will be, though feedback is the important bit here.

I think the following patch should help:

# opnsense-patch https://github.com/opnsense/core/commit/0e1e8cfa163bb27b01e33cc0d34fde2eac512e4e

Seems to have been an ordering issue in rendered content vs resize trigger.

Hold up...

Code Select Expand

dev.igc.0.fw_version: EEPROM V2.17-0 eTrack 0x80000303


This is before any of the fixes Intel pushed for related stuff.. The baseline should be 2.25.

Ok, reverted all tunables to defaults this morning and installed this kernel. Didn't have to wait long. The issue just popped up again. Again it was a down/up on the LAN interface (igc0) that resolved it. I do not see any references to watchdog timeouts, or indeed anything other that my work this morning and the reset I just did in dmesg or syslog. Here's the sysctl output on the interface while the issue was happening:

Ok, getting closer..

Can you try:

Code Select Expand

# opnsense-update -zkr 26.1.11-igc_aspm

and reboot?

Ref: https://github.com/freebsd/freebsd-src/pull/2318