Messages

I completely agree about the cheap chinsese stuff; let alone being it a possible fire hazard, one does not know which code has been "programmed" in it's various firmwares. This is why i'm so happy with my us made supermicro appliance. I'm wondering myself if i should go ahead and update the nic's firmwares. As you said, they don't release firmware updates for nothing. On the other hand, a professional brand like supermicro would release these firmware update packages when it would be needed i guess. I'm a novice in this, but i guess they know what they're doing? And there isn't an update package for my appliance, which makes me wonder if there is anything to gain except a nasty brick of my nics making my beautiful appliance unuseable.

About fixing stuff: i'm no *nix expert. The great thing about opnsense in my opinion is that it is usable for novice/medium experienced users, not only hardcore network engineers, in contrary to (for example) mikrotik, which can't be used if your not some toughguy network engineer (is my experience). Opnsense gives you the robustness of a bsd operating system and the user friendlyness of a "working out of the box" product.

I think i will contact supermicro and ask them how they feel about updating their nics on my appliance. Maybe they have a custom build update package for internal use, which they care to share?

I feel pretty stupid. And to think that, at the time when i installed all this cabling, i invested in premium cables, cat7 sftp pimf with shielded connectors, made everything by hand, pulled parts of the cable through cableducts in my walls, used premium shielded cat6 wall sockets, because i wanted to make sure.... THIS wouldn't happen. And yet it did. And i have to say, the cable that probably was causing issues, i can't see anything wrong with it, it just doesnt work. So now, to be extra sure, i placed a temporary cable which soon will be replaced by a brand new factory made cat7 sftp pimf cable (has been ordered, is on it's way). I don't want to have this misery again.

I yet have to check the link you send me for the 700mb archive in the previous post. Do you think it still would be a good idea to try and update firmware for my i210-at controllers? Or is it as they say: "if it works, don't touch it"?

Well, another day, new "adventures". I woke up today with no internet connection. Where i yesterday had a perfectly good working 1gb link between my opnsense appliance and my cablemodem, today i got nothing, not even 10mbit. So i dug a little further, and placed a small switch at my cablemodem between the network cables. It should be so that i got a solid link on the switch, but to my big surprise the link going all the way from my cablemodem to my opnsense box in my attick gave the exact same problems, not being able to make a link between devices. So i was shocked because that meant there was something wrong with my cabling OR my NIC. So i went upstairs to the attick, just randomly pulled the network cable going from my appliance to my network wall socket, replaced it with a factory made cable, and i immediately got a 1gb link! Hurray!

Now lets hope it indeed was that stupid(!) cable and from now on everything will work as it always have been.

Keep you posted.

Was it the Dell tool you used? Their download for a "v3.30" looks like i210 tool + firmware.
https://www.dell.com/support/home/en-us/drivers/driversdetails?driverid=5r8tk

Yes i used the Dell tool, booted windows to go and ran it on windows, but it gave me "update not available".

[1] igb1: EEPROM V3.16-0 eTrack 0x800004d9

It's was on 3.22 now? Hmmm, that does not seem to align with your output post #17. Your EEPROM looks like 3.16, or it was.
Also, I do believe v3.30 or higher is available from somewhere.

Maybe the tool did do upgrade to 3.22. What does "dmesg | grep igb" show you now?

Also to note, integrator's like SM, Asrock, ASUS, HP Dell, etc etc etc, don't care to build firmware upgrades for flashable devices unless they really need to. Some like Dell and others will provide flash images when security issues demand it. Sometimes the integrator builds the firmware to suit their needs or restrictions, other times a device manufacturer has full-featured firmware. As example, some years ago I had a DVD-rw drive in my PC, but the model I had could not rw Blueray. Well, turns out it was only firmware change that was needed, I exported my existing firmware and applied a mod, now it can rw blueray (had to do it this way because the firmware is very specific to some things in the drive). The maker of dvd drive sells the blueray-enabled device for more money, same drive, different words on the box, different firmware.

The fun world of firmware and drivers.

Yes it was on 3.22 . The screenshot which i made (and failed to upload) shows 3.22 being the decimal version, and 3.16 the hex version. This is a bit confusing. The tool showed for both nics "Status: update not available". And then "Tool execution completed with the following status: Device not found." (although before this sentence it shows the both i210 nics).

Well, this was a LOT of work. Upgrading the firmware on linux was too hard, i didn't understand that. So i created a windows to go live usb stick (which took a LONG time), booted from it (which also took a LONG time), and started the windows firmware upgrade package.

And then.... nothing 😔. The tool showed my two i210-at nics, with the message that there werent any updates available. According to the tool, my nics are on fw 3.22 now.

What i did find was other folks asking for firmware for their intel nics on the intel boards, which then got replied by the intel folks by stating that for in order to get access to the firmware for a  intel nic, you have to sign a NDA approval (!) to even get possibly access to the firmware. This is not a matter of just downloading the fw.

An other thing is that sometimes the hardware vendor for the appliance can provide nic firmwares, but in my case, there is no such update package on the supermicro website for my appliance, so that too is a dead end.

But today it seems is the day of miracles. Because i did not touch any network cable, i only tried updating the nic firmwares, but i did reboot the opnsense appliance a couple of times and now miraculously my wan port negotiated at 1000baset and my network internet throughput is passing the 100mbit mark again. My subscription is for 125/25 and my actual speed is now 128.2 / 25.78 . Nice. Let's hope and pray it stays this way.



-edit: my tinypic screenshot isn't loading, don't know how or why...

[1] igb0: <Intel(R) I210 (Copper)> port 0xd000-0xd01f mem 0x88900000-0x8897ffff,                          0x88980000-0x88983fff at device 0.0 on pci2
[1] igb0: EEPROM V3.16-0 eTrack 0x800004d9
[1] igb0: Using 1024 TX descriptors and 1024 RX descriptors
[1] igb0: Using 4 RX queues 4 TX queues
[1] igb0: Using MSI-X interrupts with 5 vectors
[1] igb0: Ethernet address: **:**:**:**:**:**
[1] igb0: netmap queues/slots: TX 4/1024, RX 4/1024
[1] igb1: <Intel(R) I210 (Copper)> port 0xc000-0xc01f mem 0x88700000-0x8877ffff,                          0x88780000-0x88783fff at device 0.0 on pci5
[1] igb1: EEPROM V3.16-0 eTrack 0x800004d9
[1] igb1: Using 1024 TX descriptors and 1024 RX descriptors
[1] igb1: Using 4 RX queues 4 TX queues
[1] igb1: Using MSI-X interrupts with 5 vectors
[1] igb1: Ethernet address: **:**:**:**:**:**
[1] igb1: netmap queues/slots: TX 4/1024, RX 4/1024
[17] igb1: link state changed to UP
[29] igb1: link state changed to DOWN
[33] igb1: link state changed to UP
[548] igb1: link state changed to DOWN
[552] igb1: link state changed to UP
[1] igb0: <Intel(R) I210 (Copper)> port 0xd000-0xd01f mem 0x88900000-0x8897ffff,                          0x88980000-0x88983fff at device 0.0 on pci2
[1] igb0: EEPROM V3.16-0 eTrack 0x800004d9
[1] igb0: Using 1024 TX descriptors and 1024 RX descriptors
[1] igb0: Using 4 RX queues 4 TX queues
[1] igb0: Using MSI-X interrupts with 5 vectors
[1] igb0: Ethernet address: **:**:**:**:**:**
[1] igb0: netmap queues/slots: TX 4/1024, RX 4/1024
[1] igb1: <Intel(R) I210 (Copper)> port 0xc000-0xc01f mem 0x88700000-0x8877ffff,                          0x88780000-0x88783fff at device 0.0 on pci5
[1] igb1: EEPROM V3.16-0 eTrack 0x800004d9
[1] igb1: Using 1024 TX descriptors and 1024 RX descriptors
[1] igb1: Using 4 RX queues 4 TX queues
[1] igb1: Using MSI-X interrupts with 5 vectors
[1] igb1: Ethernet address: **:**:**:**:**:**
[1] igb1: netmap queues/slots: TX 4/1024, RX 4/1024
[17] igb1: link state changed to UP
[29] igb1: link state changed to DOWN
[32] igb1: link state changed to UP
[239] igb1: link state changed to DOWN
[243] igb1: link state changed to UP
[372] igb0: link state changed to UP
[386] igb0: link state changed to DOWN
[390] igb0: link state changed to UP
[485] igb0: link state changed to DOWN
[508] igb0: link state changed to UP
[515] igb0: link state changed to DOWN
[530] igb0: link state changed to UP
[533] igb0: link state changed to DOWN
[535] igb0: link state changed to UP
[674] igb0: link state changed to DOWN
[675] igb1: link state changed to DOWN
[680] igb1: link state changed to UP
[1] igb0: <Intel(R) I210 (Copper)> port 0xd000-0xd01f mem 0x88900000-0x8897ffff,                          0x88980000-0x88983fff at device 0.0 on pci2
[1] igb0: EEPROM V3.16-0 eTrack 0x800004d9
[1] igb0: Using 1024 TX descriptors and 1024 RX descriptors
[1] igb0: Using 4 RX queues 4 TX queues
[1] igb0: Using MSI-X interrupts with 5 vectors
[1] igb0: Ethernet address: **:**:**:**:**:**
[1] igb0: netmap queues/slots: TX 4/1024, RX 4/1024
[1] igb1: <Intel(R) I210 (Copper)> port 0xc000-0xc01f mem 0x88700000-0x8877ffff,                          0x88780000-0x88783fff at device 0.0 on pci5
[1] igb1: EEPROM V3.16-0 eTrack 0x800004d9
[1] igb1: Using 1024 TX descriptors and 1024 RX descriptors
[1] igb1: Using 4 RX queues 4 TX queues
[1] igb1: Using MSI-X interrupts with 5 vectors
[1] igb1: Ethernet address: **:**:**:**:**:**
[1] igb1: netmap queues/slots: TX 4/1024, RX 4/1024
[17] igb1: link state changed to UP
[29] igb1: link state changed to DOWN
[32] igb0: link state changed to UP
[33] igb1: link state changed to UP
[1] igb0: <Intel(R) I210 (Copper)> port 0xd000-0xd01f mem 0x88900000-0x8897ffff,                          0x88980000-0x88983fff at device 0.0 on pci2
[1] igb0: EEPROM V3.16-0 eTrack 0x800004d9
[1] igb0: Using 1024 TX descriptors and 1024 RX descriptors
[1] igb0: Using 4 RX queues 4 TX queues
[1] igb0: Using MSI-X interrupts with 5 vectors
[1] igb0: Ethernet address: **:**:**:**:**:**
[1] igb0: netmap queues/slots: TX 4/1024, RX 4/1024
[1] igb1: <Intel(R) I210 (Copper)> port 0xc000-0xc01f mem 0x88700000-0x8877ffff,                          0x88780000-0x88783fff at device 0.0 on pci5
[1] igb1: EEPROM V3.16-0 eTrack 0x800004d9
[1] igb1: Using 1024 TX descriptors and 1024 RX descriptors
[1] igb1: Using 4 RX queues 4 TX queues
[1] igb1: Using MSI-X interrupts with 5 vectors
[1] igb1: Ethernet address: **:**:**:**:**:**
[1] igb1: netmap queues/slots: TX 4/1024, RX 4/1024

hostb0@pci0:0:0:0:      class=0x060000 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f00 subvendor=0x15d9 subdevice=0x0816
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor Z36xxx/Z37xxx Series SoC Transaction Register'
    class      = bridge
    subclass   = HOST-PCI
vgapci0@pci0:0:2:0:     class=0x030000 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f31 subvendor=0x15d9 subdevice=0x0816
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor Z36xxx/Z37xxx Series Graphics & Display'
    class      = display
    subclass   = VGA
ahci0@pci0:0:19:0:      class=0x010601 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f23 subvendor=0x15d9 subdevice=0x0816
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor E3800 Series SATA AHCI Controller'
    class      = mass storage
    subclass   = SATA
none0@pci0:0:26:0:      class=0x108000 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f18 subvendor=0x15d9 subdevice=0x0816
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine'
    class      = encrypt/decrypt
pcib1@pci0:0:28:0:      class=0x060400 rev=0x0e hdr=0x01 vendor=0x8086 device=0x0f48 subvendor=0x15d9 subdevice=0x0816
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor E3800 Series PCI Express Root Port 1'
    class      = bridge
    subclass   = PCI-PCI
pcib2@pci0:0:28:2:      class=0x060400 rev=0x0e hdr=0x01 vendor=0x8086 device=0x0f4c subvendor=0x15d9 subdevice=0x0816
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor E3800 Series PCI Express Root Port 3'
    class      = bridge
    subclass   = PCI-PCI
pcib3@pci0:0:28:3:      class=0x060400 rev=0x0e hdr=0x01 vendor=0x8086 device=0x0f4e subvendor=0x15d9 subdevice=0x0816
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor E3800 Series PCI Express Root Port 4'
    class      = bridge
    subclass   = PCI-PCI
ehci0@pci0:0:29:0:      class=0x0c0320 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f34 subvendor=0x15d9 subdevice=0x0816
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor Z36xxx/Z37xxx Series USB EHCI'
    class      = serial bus
    subclass   = USB
isab0@pci0:0:31:0:      class=0x060100 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f1c subvendor=0x15d9 subdevice=0x0816
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor Z36xxx/Z37xxx Series Power Control Unit'
    class      = bridge
    subclass   = PCI-ISA
ichsmb0@pci0:0:31:3:    class=0x0c0500 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f12 subvendor=0x15d9 subdevice=0x0816
    vendor     = 'Intel Corporation'
    device     = 'Atom Processor E3800/CE2700 Series SMBus Controller'
    class      = serial bus
    subclass   = SMBus
igb0@pci0:2:0:0:        class=0x020000 rev=0x03 hdr=0x00 vendor=0x8086 device=0x1533 subvendor=0x15d9 subdevice=0x1533
    vendor     = 'Intel Corporation'
    device     = 'I210 Gigabit Network Connection'
    class      = network
    subclass   = ethernet
pcib4@pci0:3:0:0:       class=0x060400 rev=0xab hdr=0x01 vendor=0x10b5 device=0x8605 subvendor=0x15d9 subdevice=0x0816
    vendor     = 'PLX Technology, Inc.'
    device     = 'PEX 8605 PCI Express 4-port Gen2 Switch'
    class      = bridge
    subclass   = PCI-PCI
pcib5@pci0:4:1:0:       class=0x060400 rev=0xab hdr=0x01 vendor=0x10b5 device=0x8605 subvendor=0x15d9 subdevice=0x0816
    vendor     = 'PLX Technology, Inc.'
    device     = 'PEX 8605 PCI Express 4-port Gen2 Switch'
    class      = bridge
    subclass   = PCI-PCI
pcib6@pci0:4:2:0:       class=0x060400 rev=0xab hdr=0x01 vendor=0x10b5 device=0x8605 subvendor=0x15d9 subdevice=0x0816
    vendor     = 'PLX Technology, Inc.'
    device     = 'PEX 8605 PCI Express 4-port Gen2 Switch'
    class      = bridge
    subclass   = PCI-PCI
pcib7@pci0:4:3:0:       class=0x060400 rev=0xab hdr=0x01 vendor=0x10b5 device=0x8605 subvendor=0x15d9 subdevice=0x0816
    vendor     = 'PLX Technology, Inc.'
    device     = 'PEX 8605 PCI Express 4-port Gen2 Switch'
    class      = bridge
    subclass   = PCI-PCI
igb1@pci0:5:0:0:        class=0x020000 rev=0x03 hdr=0x00 vendor=0x8086 device=0x1533 subvendor=0x15d9 subdevice=0x1533
    vendor     = 'Intel Corporation'
    device     = 'I210 Gigabit Network Connection'
    class      = network
    subclass   = ethernet
ahci1@pci0:7:0:0:       class=0x010601 rev=0x11 hdr=0x00 vendor=0x1b4b device=0x9230 subvendor=0x1b4b subdevice=0x9230
    vendor     = 'Marvell Technology Group Ltd.'
    device     = '88SE9230 PCIe 2.0 x2 4-port SATA 6 Gb/s RAID Controller'
    class      = mass storage
    subclass   = SATA

I'm sorry, i'm a bit confused here. I'm not very familiar with *nix systems. I tried to follow up on @BrandyWine 's post, where he mentioned:

Also check if the proper driver is listed from kernel (the if_ items, etc), because there was a kernel update.
ls /boot/kernel | grep -v kernel

My ifconfig -a shows me "igc" for the coppers, so in kernel list i see "if_igc.ko", etc.

So i did that, logged in with putty in my opnsense box, and ran ls /boot/kernel | grep -v kernel . After this, i got a long list of modules, where i found if_igb.ko and if_igc.ko . I'm actually not sure what i'm looking at .

After reading his remark for the thirtied time ;-) , i know understand the ifconfig -a remark, and yes, now i understand that the interface name was meant. In my case it is igb0 and igb1.

The result of kldstat is:

# kldstat
Id Refs Address                Size Name
 1   56 0xffffffff80200000  216dad8 kernel
 2    3 0xffffffff8236e000    908a0 pf.ko
 3    1 0xffffffff823ff000     4be0 if_enc.ko
 4    1 0xffffffff82404000     3c10 pflog.ko
 5    1 0xffffffff82408000   5e9300 zfs.ko
 6    1 0xffffffff829f2000    1e280 opensolaris.ko
 7    1 0xffffffff82a11000    11a78 pfsync.ko
 8    1 0xffffffff82a23000    16650 if_lagg.ko
 9    2 0xffffffff82a3a000     3558 if_infiniband.ko
10    1 0xffffffff82a3e000     aa30 if_gre.ko
11    1 0xffffffff82a4a000     fb90 carp.ko
12    1 0xffffffff82a5a000     ed60 if_bridge.ko
13    2 0xffffffff82a69000     8990 bridgestp.ko
14    1 0xffffffff83710000     4250 ichsmb.ko
15    1 0xffffffff83715000     2178 smbus.ko
16    1 0xffffffff83718000     3360 uhid.ko
17    1 0xffffffff8371c000     3360 wmt.ko
18    1 0xffffffff83720000     4364 ums.ko
19    1 0xffffffff83725000     4850 nullfs.ko
20    1 0xffffffff8372a000     20f0 coretemp.ko

I don't know how to find out which flavour my i210 controller is without pulling the entire firewall out of the 19" rack. Is there an easier way to find out?
According to this website, it should be the i210-AT nic.

Well, i haven't sit still, tried a lot of things. I pulled my supermicro opnsense appliance from its rack, cleaned it, replaced it's ssd, noticed there was a bios firmware upgrade for the supermicro appliance  so upgraded that too, did a complete fresh zfs reinstall of opnsense.

After that, pulled most network cables from their sockets going from and to the cablemodem and cleaned them with contact spray (i think this is called deoxit in the states), tried a different network cable going from cablemodem to the wall network socket (from there my wan cable goes to my rack which sits in my attick), and after all of this: still no luck. My wan interface only works if i put it on fixed 100mbit rate.

To clearify my situation: before and after updating to 25.7.2, i did nothing to my network cables, they all are nicely installed in regulation tubes in my walls, going from (shielded) socket to (shielded) socket. Never had any issues with these cables.

I also noticed i was previously running opnsense in bios csm mode, now i disabled all legacy stuff and are running in native uefi mode. Also changes nothing.

from dmesg:

[1] igb0: <Intel(R) I210 (Copper)> port 0xd000-0xd01f mem 0x88900000-0x8897ffff,0x88980000-0x88983fff at device 0.0 on pci2
[1] igb0: EEPROM V3.16-0 eTrack 0x800004d9
[1] igb0: Using 1024 TX descriptors and 1024 RX descriptors
[1] igb0: Using 4 RX queues 4 TX queues
[1] igb0: Using MSI-X interrupts with 5 vectors
[1] igb0: Ethernet address: ##:##:##:##:##:##
[1] igb0: netmap queues/slots: TX 4/1024, RX 4/1024

Same goes for igb1

It appears that if_igc.ko is loaded.

Now i got this brilliant idea 😂 of placing a small ethernet switch inbetween the cablemodem and the network cable going to the firewall. Maybe this will help shed some light to the current situation. Haven't done it yet, but if it will result in a solid stable 1gbit link going all the way from my opnsense firewall to my cablemodem, then i would know that my opnsense box and the network cables arent the culprit. I didnt have the time to try it yet, but this will be my next "test". I have had some downtime from my isp recently where they where working on their network, and i want to rule out that they pushed a dodgy firmware to my cablemodem.

I did unplug the ethernet cable from my cable modem. This resulted in having an 100mbit link (after i set the nic speed manually to 100mbit). On autosense , even after unplugging the cable, it keeps negotiating link speed, the green nic led keeps flashing on and of slowly, but there is no final link. I can't replace cables because my cablemodem and opnsense firewall are on different floors and i use fixed cables (cat6/7 pimf high quality shielded). I did power cycle the cable modem, i did reboot my opnsense appliance but did not give it a cold reboot.

It's ok for me to do a reinstall, it should be a nice oppurtunity to do a fresh install after years of updating existings installs, replacing its ssd at the same time. My only concern is that i use dnscrypt-proxy and i dont know how to backup the whitelist that i manually made. When i backup my current opnsense config and restore it to a new installation, will all this be reinstalled correctly in the new install, including the dnscrypt-proxy whitelist?

I have a very simple setup which consists of a supermicro 1he appliance with intel nics running opnsense. It has an intel j1900 cpu.

I always run updates when they are released by opnsense and never had any issues, until now.

After updating to 25.7.2 my wan interface suddenly can't make an fysical network link to my cable modem. The link-led flashes on and of on my modem. When i fixate the speed to 100mbit fullduplex the link works again. But on autosense , which normally results in 1000base full duplex the link fails. I disabled all hardware offloading for the nic but that seemed to make no difference. In order to keep access to the internet i now have to run on 100mbit otherwise the link fails.

The nics in my appliance are two intel i210 nics, which until now never have gave my any problems. Can this please be fixed so that i can use full bandwith of my internet connection again?

I seem to have stumbled upon this problem a couple of years ago, back then i put aside the appliance, only to encounter the same problem again. Wireless issues have been solved in the meantime (atheros bsd drivers where developed), but the emmc problems persists.

@newsense I am aware that opnsense isnt directly involved in hardware support. Even better: i almost gave up on the emmc chip, only to discover that it actually does work with certain settings in the uefi and with booting linux (that original OS on this appliance probably also was linux based). I continued tinkering with the emmc settings, but this lead to no improvement in opnsense.  I did send an inquery for newer firmware. I hope that there will come a response to this, you never know with these companys.

@FraLem I havent thought of this actually, seems like a good test. This will be my next "endevour" with this device.

Another thing that came to mind. All of this made me think about "the olden days", back when lots of us where busy installing *sense on the well known watchguard firebox appliances. On these devices, there was a problem using cf cards with basic *sense settings, it would boot. You needed to disable dma for the CF reader in the loader.conf file. After that, running in PIO mode, all was fine. I wonder if these emmc troubles are of the same kind. I did actually disabled adma and after that dma, only to run in pio mode. But this gave me no improvement. Are there loader.conf settings that can be made for the emmc device in bsd, such as disabling dma accesss?

So i made a little progress here. I first started to find out if other distributions would or would not work with the onboard emmc chip. After booting the other *sense, it inmediately gave exactly the same error in the bootlog as opnsense. Then i started to run some dos tools, trying to wipe the emmc, but to no avail. dban wouldnt start as a result of console redirection.

At this point, i was wondering if the emmc chip is actually still working, or it maybe being defective? I tried a couple of emmc / sdcard settings in the uefi, and with result.

I figured it would make sense to first start some sort of linux distribution, with linux generally supporting a broader ranger of hardware. I found ipfire and first started it before the emmc / bios settings alterations, with no luck. ipfire wouldnt even detect the emmc chip. Then i changed some emmc settings (see screenshot), for example to 32bit and a lower standard (sd 2.0). And that did the trick, ipfire found the emmc device and i was even able to install and boot ipfire from the cyberoams internal 8gb emmc storage.

I expected this to be the same with opnsense, so with big hopes i booted opnsense, only to find out that it still wouldnt work with the emmc chip and still gives the same controller timeout error.

So with all of this, i now know that the emmc chip and controller is in a good working order, ipfire runs with no issues whatsoever. Only opnsense is refusing to support the emmc chip.

I'm trying to run opnsense 22.7 on an cyberoam appliance. Every hardware part seems to be supported, except that i'm experiencing problems with it's onboard emmc module.

To be specific, this part from the bootlog is where things seem to go wrong:

sdhci_pci0-slot0: Controller timeout
sdhci_pci0-slot0: ============== REGISTER DUMP ==============
sdhci_pci0-slot0: Sys addr: 0x00000000 | Version:  0x00001001
sdhci_pci0-slot0: Blk size: 0x00000004 | Blk cnt:  0x00000001
sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000002
sdhci_pci0-slot0: Present:  0x01ff0106 | Host ctl: 0x00000003
sdhci_pci0-slot0: Power:    0x0000000f | Blk gap:  0x00000000
sdhci_pci0-slot0: Wake-up:  0x00000000 | Clock:    0x00004007
sdhci_pci0-slot0: Timeout:  0x0000000d | Int stat: 0x00000000
sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa
sdhci_pci0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
sdhci_pci0-slot0: Caps:     0x21a632b2 | Caps2:    0x00000570
sdhci_pci0-slot0: Max curr: 0x00c80064 | ADMA err: 0x00000000
sdhci_pci0-slot0: ADMA addr:0x00000000 | Slot int: 0x000000ff
sdhci_pci0-slot0: ===========================================
sdhci_pci0-slot0: Controller timeout
sdhci_pci0-slot0: ============== REGISTER DUMP ==============
sdhci_pci0-slot0: Sys addr: 0x00000000 | Version:  0x00001001
sdhci_pci0-slot0: Blk size: 0x00000004 | Blk cnt:  0x00000001
sdhci_pci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000012
sdhci_pci0-slot0: Present:  0x01ff0206 | Host ctl: 0x00000003
sdhci_pci0-slot0: Power:    0x0000000f | Blk gap:  0x00000000
sdhci_pci0-slot0: Wake-up:  0x00000000 | Clock:    0x00004007
sdhci_pci0-slot0: Timeout:  0x0000000d | Int stat: 0x00000001
sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa
sdhci_pci0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
sdhci_pci0-slot0: Caps:     0x21a632b2 | Caps2:    0x00000570
sdhci_pci0-slot0: Max curr: 0x00c80064 | ADMA err: 0x00000000
sdhci_pci0-slot0: ADMA addr:0x00000000 | Slot int: 0x000000ff
sdhci_pci0-slot0: ===========================================

The scb-6901 appliance supports both uefi and legacy booting. Strangely enough, while booting in pure uefi mode (with csm disabled) the emmc device disappears.

So what i've tried so far:
Booting opnsense 22.7 vga image from usb in uefi mode with csm (legacy) module disabled
Booting opnsense 22.7 serial image from usb in csm (legacy) mode

Read this topic that suggests emmc support should be there.

Read this topic and tried putting "hw.sdhci.enable_msi=0" in the loader.conf file . Even that didnt make much of a difference (one would expect the emmc device to be disabled?)

Putting the "sd host controller version" (thats what the uefi/bios calls the emmc device/controller) in "2.0"mode. And after that, putting it in "3.0" mode.
Changed the sd device in the uefi from adma to pio mode. Made no difference.

So now i've tried as much as anything i could think of. Does anyone have a clue how to get the emmc device not timing out?

This seems to be a problem which has occured somewhere along the line in the latest updates. Now reports from broken ipv6 links start to show up, for example in the fb opnsense group. I just checked, and it seems that my ipv6 connection also is dead, not working.

Can a opnsense dev pick this up?