Messages

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?

Yep, next version

Thank you! As  your profile states, you're actually a "hero"  :D

You have to deselect all severities, then they should work again

This works for me too. Should be nice if this isnt necessary on the next release. can this be fixed?

Thanks, it works for unbound, but not for DNScryptProxy :-\ The status remains as "No results found".

Same exact issue here. Logs appear in unbound after altering the severity level, but not in dnscrypt-proxy.

I just upgraded from 19.7.7 to 22.1 and encountered the same error. When i check the logs in cli , it seems dnscrypt-proxy is working perfectly fine, is resolving names and does what it supposed to do. Also the logs are populated in the related logfiles. Only problems is that nothing, no logs, are showing in the gui for dnscrypt-proxy.

btw, i followed this howto to get dnscrypt-proxy working with unbound:
https://forum.opnsense.org/index.php?topic=10670.msg118634#msg118634

Can this be fixed?   

I did an update to 21.1.9, but the problem still exists. Am i doing something wrong? Or where the patches not applied to the new opnsense release? I can't find anything on dnscrypt  in the changelog.

It seems i also have this issue. Took me a while to find this topic. Is there any progress in fixing this matter?

I just ran into this problem with a different appliance (cyberoam) which has emmc onboard, gives the exact same error. Opnsense 20.7  .

Will there be, at some point, a fix for this problem?

i double checked, last version was indeed 19.7.8:

Jan 20 18:38:24    pkg-static: opnsense upgraded: 19.7.8 -> 19.7.9_1

I called my cable operator and did a factory reset of the cablemodem. Would it be wise to wait for a day or so and see if this makes a difference? There where no discrepancies to be found in modem firmware, hope this solves my issues...

What kind of data would we need to further investigate?

This keeps happening. It is becoming a routine. Starting the day with doing a dhcp release/renew. Any news on this?

The previous stable one. That would be  19.7.8 . I always update to the latest stable release when they come out. Just had to release/renew because wan was gone again.