2.4 Hanging during on Apollo Lake
-
No idea as I've never been in this situation before, but I've read posts from others who have been.
-
what J3355 board are you using? What NICs are you using?
What issues did you run into with the installation?
I've successfully installed 2.4.0 BETA to J3355B-ITX a number of times on a number of different builds, I've even used a drive where pfSense was installed on a different computer just fine, I've changed NIC's, etc. Never any issues.
-
Also using a J3355B-ITX.. NIC is a HP NC364T.
-
what issues exactly did you get during installation?
-
It was complaining about invalid console.
-
This might be the same FreeBSD 11.1 issue with Apollo Lake
https://forums.freebsd.org/threads/59653/I'm having the same issue mentioned in that thread, J3455 with UEFI stuck at HPET. I'm not sure FreeBSD is working on a fix , I cant find any bug report with similar description.
-
Interesting but doesn't really make sense.
After installing on another host, I was able to boot in 2.4 just fine on the j3355. It's only when I restored configs I froze.
There are others who seem to be running the j3355 just fine looking on this forum and a general google search.
-
if you have CSM mode turned on then it is not the same issue. Have you tried while network cables plugged in?
-
Apollo Lake chipset.
I managed to install and run the latest RC version as follows :- Boot from image
- At first loader menu choose to boot in safe mode
- Complete installation in safe mode
- Before final reboot choose to add manual changes (goes to prompt)
- Add to /etc/loader.conf the following statement : hint.hpet.0.clock="0"
I have been running the 11.1 based version since yesterday without major problems, but I noticed some recurring events "xhci0: Resetting controller" which led to resetting the whole USB subsystem.
Massimo
-
I'm aware of this workaround from the link I've pasted. While I'm OK with this solution, The Apollo Lake support is broken and need a proper fix.
Already reported to FreeBSD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222908
Feel free to add more information to the report. -
Should this tweak be done in /boot/loader.conf.local?
-
I have it in /boot/loader.conf and it works fine.
-
That gets overwritten on update correct?
-
I thought it would, but it survived reboot and upgrade.
-
Ok, looks like I've been running ok now for a few days. Despite the installation headache, it seems like pretty solid hardware. Once FreeBSD is updated to better support I'd fully endorse it.
Thanks for the help.
-
I had trouble booting up pfSense 2.4.1 on an Asrock J4205-ITX as well. It seemed to hang at
Timecounter "HPET" frequency 19200000 Hz quality 950- but activating verbose mode in the boot menu revealed that it actually further, up to```
msi: Assinging MSI-X IRQ 267 to local APIC 0 vector 52I (sort of) quickly found out that the board would boot in safe mode. The "safe mode" option which allowed it to boot was disabling SMP (verified by typing "set kern.smp.disabled=1", but that limiting the CPU to a single core was not an option I wanted to take. What finally did work was adding``` machdep.disable_msix_migration=1 ```to /boot/loader.conf.local (had to create this file - this will get read just like loader.conf, but it will not be overwritten by updates/upgrades). Note that some people attempting run various versions of FreeBSD on this board mentioned that it would only boot up when, additionally, the NIC was connected to a network. Not sure about that - I had disabled the internal Realtek NIC, but had a network connected to one of the dual Intel NIC's ports. Some more details about my hardware: Asrock J4205-ITX 2 x 8GB RAM WD Green SSD 120GB a dual 1GB NIC (Intel 82576-based, manufacturered/sold by 10Gtek®) The NIC has two 1GB ports and supports PCIe 2.0 x1, so it fits nicely with the board's PCIe 2.0 x1 slot. I disabled the board's Realtek NIC in the BIOS. The BIOS version is 1.40 (tried all four versions, 1.10, 1.20, 1.30 and 1.40, and a BIOS downgrade did not solve the boot issue by itself, so I stuck to 1.40). My BIOS settings: Intel SpeedStep Technology: Enabled CPU C States Support: C6 (tried all each setting, but had no effect on the boot issue, so I left it at default) Enhanced Halt State(C1E): Enabled Intel Virtualization Technology: Enabled VT-d: Disabled Power Gear: Normal Mode DRAM Frequency: Auto DRAM Voltage: Auto Primary Graphics Adapter: Onboard Share Memory: Auto (tried to set this to 64MB, but didn't work - perhaps the GPU wanted more, as it was connected to a 4K display via HDMI) Onboard HD Audio: Disabled Onboard LAN: Disabled (I decided to go for an Intel NIC right from the start) PCIE1 Link Speed: Auto WAN Radio: Disabled BT Enabled: Disabled Deep S5: Disabled Restore on AC/Power Loss: Power On (the box sits behind a UPS…but you never know) Good Night LED: Disabled SATA Controller(s): Enabled SATA Aggressive Link Power Management: Disabled Hard Disk S.M.A.R.T: Enabled ASMedia SATA3 Mode: Disabled (the SSD is connected to the SATA3_2 (Intel) port, easier to reach than the SATA3_1 port) Serial Port 1: Disabled Suspend to RAM: Auto ACPI HPET Table: Enabled (this was one of the first I tried to diabled, but had no effect on the boot issue) All Power-On-options are set to Disabled Legacy USB Support: Enabled CPU Fan 1 Setting: Full Speed (there is no CPU fan) Chassis Fan 1 Setting: Automatic mode (the case does have a nce silent fan, so I decided to plug it in) Chassis Fan 1 Temp Source: Monitor M/B Target CPU Temperature: 50 °C/122 °F Target Fan Speed: Level 9 Case Open Feature: Disabled Secure Boot: Disabled Intel(R) Platform Trust Technology: Enabled Boot Option #1: UEFI OS (SATA 3_2) Fast Boot: Disabled (this seems to with Windows 10 only anyway) Boot From Onboard LAN: Disabled Setup Prompt Timeout: 1 Boot Num-Lock: On Boot Beep: Disabled (I don't a beeper connected anyway) Full Screen Logo: Disabled Boot Failure Guard Message: Enabled CSM: Disabled In the pfSense Advanced Setup, Cryptographic & Thermal Hardware, I enabled AES-NI and selected the Intel Core on-die sensors. And that's what my complete load.conf.local looks like (based on the assumption that with 16GB RAM, I don't need to be conservative):hw.igb.rxd=4096
hw.igb.txd=4096
net.pf.states_hashsize=2097152
net.pf.source_nodes_hashsize=65536
hw.igb.fc_setting=0
hw.igb.rx_process_limit="-1"
hw.igb.tx_process_limit="-1"
net.inet.tcp.syncache.hashsize="2048"
net.inet.tcp.syncache.bucketlimit="16"
net.inet.tcp.syncache.cachelimit="32768"
machdep.disable_msix_migration=1The performande settings were mostly inspired by this post: https://forum.pfsense.org/index.php?topic=113496.0 -
Thank you Klaws, I tried your setting and everything seems to be working better than before.
However, I was hoping it would help with stability problem but it didn't. I still have the occasional lockups, which I can't determine the source of it. Have you encountered any instability problems with j4205, noting i have J3455B-ITX?
-
I had no issues with hangs or instability so far. No reboot or anything for two weeks flat, since my post on October 30th, actually.
Load on my box is probably low - WAN speed is 100MBit/s and I have seen a maximum of 80.000 states or so. Well, squid taxes the CPU a bit, but the box is still not driven to the limits. The HD is an SSD - some WD "Green" 100GB thingy. RAM are two KVR16LS11/8 (giving me 16GB in total), which seems to test nice and stable with memtest x86 and the NIC is a "10Gtek
für Intel E1G42ET, Intel 82576 Chip Gigabit Ethernet Konvergierter Netzwerkadapter (NIC), Dual RJ45 Kupfer Ports, PCI Express 2.0 X1" (currently sold out at German Amazon). I have disabled the onboard Realtek NIC in the BIOS and only use the two Intel ports from the add-on board. There are some rumors that Realtek actually has a stable driver for the NIC, but the default driver in most (or all) FreeBSD kernel versions appears to have stability issues, so I didn't start experimenting around and went for the Dual Intel path right away. -
Hi,
same problem of post #18 here on J3455M-E mobo; I was doing a fresh install because upgrading from 2.4.0 to 2.4.1 through the web console brought to an increase of load average always over 1.
Up to now the only solution was to install 2.3.4 version and wait for a solution on something that seems related to the last kernel.
