PANIC: SDHCI: Command execution impossible, command inhibit

[Nasina]

Attempting to boot Beta 5 Test Candidate 0, as well as any nightly build hrev57689 and up on my Dell Latitude 3440 (2013) throws me into the KDL on startup with the panic message "Command execution impossible, command inhibit" on the "SD bus controller" thread. I can continue past the KDL and boot the system fine, and from there, the system runs without issues. The issue does not occur in Beta 4 or any nightly build hrev57683 and below.

I've attatched a syslog, as well as the output of "listdev" and "listimage | grep drivers" to the ticket from a usb boot of hrev58067. I'd use the latest nightly, but any nightly build hrev58095 and up freeze before they finish the boot splash screen, likely due to the issue mentioned in ​this thread in the discussion forum.

Going into the bootloader and ticking "Disable ACPI" fixes both the SD bus controller issue, and the freeze on startup in the latest nightly. I'm currently testing with the x86_64 builds.

[waddlesplash]

Please try with this build (which will probably become RC1): ​https://s3.us-east-1.wasabisys.com/haiku-release-candidates/x86_64/haiku-r1beta5-hrev57937_113-x86_64-anyboot.iso

This contains the fix for #18536 but not the recent ACPI regression; I suspect the fix for #18536 may also fix your problem.

[Nasina]

Still seems to occur. I'll attach a syslog from this build.

[waddlesplash]

Ah, it appears support was added for your SDHCI controller in hrev57684; previously it just wasn't supported. It appears to be an ACPI-enumerated controller, hence why this panic doesn't occur when ACPI is disabled.

I guess for now you can just blocklist the driver until someone comes up with a fix (or we decide to disable this assertion and fail more gracefully.)

[CodeforEvolution]

Looking at the code here: ​https://github.com/haiku/haiku/blob/c936122410bc6e704c35de5267e3a34f5450d366/src/add-ons/kernel/busses/mmc/sdhci.cpp#L168

I'm thinking that it may be best to disable the panic, and replace it with an ERROR(). The first panic happens as soon as the SDHCI controller is attempted to be reset here: ​https://github.com/haiku/haiku/blob/c936122410bc6e704c35de5267e3a34f5450d366/src/add-ons/kernel/bus_managers/mmc/mmc_bus.cpp#L173

So, despite this coming release being a Beta, I think it may be better to avoid a panic (even a continuable one) on what may be a controller-specific quirk.

[bpresles]

I've the same issue with an Intel NUC D54250WYKH, probably because of the mSATA connector (which is empty in my case).

Disabling ACPI make the OS start, but it freezes completely after a random amount of time. I'll provide a debug log tonight once I can start it again.

Btw, it was running fine on Beta 4 with ACPI enabled. Maybe if the PANIC is fixed so that it can boot with ACPI, the random freezes I experience would disappear?

[pulkomandy]

Certainly not because of mSATA, which is SATA (not SD/MMC).

For this specific issue, the best thing to do will be to block/disable the sdhci_acpi driver.

Or, as mentionned in the earlier comment, you can just type "continue" at the panic and continue using your system normally.

[Nasina]

Just as an update, disabling the SDHCI driver did work on my end, and I haven't had any issues on this hardware since.

If you need me to test this again in the future, let me know.

[bpresles]

Freezes when disabling ACPI - Syslog

[bpresles]

Freezes when ACPI disabled - listdrivers

[bpresles]

Freezes when APCI disabled - listdev

[bpresles]

Freezes when ACPI disabled - listusb

[bpresles]

Replying to pulkomandy:

Certainly not because of mSATA, which is SATA (not SD/MMC).

For this specific issue, the best thing to do will be to block/disable the sdhci_acpi driver.

Or, as mentionned in the earlier comment, you can just type "continue" at the panic and continue using your system normally.

No I can't type anything on KDL when the PANIC happens. Disabling ACPI did work but with freezes (see attachments).

Also there is no SD/MMC card reader on this device AFAIK.

[bpresles]

I confirm that disabling the sdhci MMC busses add-ons work when I do it from safe mode options in bootloader.

But when I try to make it permanent by following the guide here: ​https://www.haiku-os.org/guides/daily-tasks/disable-package-entries, it doesn't work.

I create the file /boot/system/settings/packages with the following content:

Package haiku  {
    BlockedEntries {
        add-ons/kernel/busses/mmc/sdhci
    }
}

But it doesn't seem to take it in account. Did I do something incorrectly?

[waddlesplash]

That looks correct to me. I tried putting exactly what you have posted into the packages settings file on one of my VMs, rebooted, and it worked.

[bpresles]

I use EFI boot loader, is that changing something? Did I place the packages settings file in the right place for beta5 (/boot/system/settings/packages (without any extension)) (I created it, as it didn't exist)?

[waddlesplash]

The loader used shouldn't change anything, this file is read by the kernel.

Yes, that's the right path, and indeed it won't exist by default.

[waddlesplash]

Ah, actually you may need to blocklist the file in the "boot" path too, because this module is also loaded as part of the boot process and not just on-demand later on.

[bpresles]

And how do you do that?

[bpresles]

I finally made it work! Contrary to what is indicated in ​https://www.haiku-os.org/guides/daily-tasks/disable-package-entries, the good syntax was to replace BlockedEntries by EntryBlacklist:

Package haiku  {
    EntryBlacklist {
        add-ons/kernel/busses/mmc/sdhci
    }
}

This is a bit odd as I found this information on an old blog post indicated as "preserved for historical reason" and that "Up to date information is maintained in the “daily tasks” guide." (with the previous url linked), here : ​https://www.haiku-os.org/blog/barrett/2013-12-15_how_permanently_blacklist_package_file/

This way it boots perfectly fine, without having to enter in safe boot options manually ;)

[waddlesplash]

It appears there's some code in the bootloader that doesn't check the correct name but still uses the "legacy" one, that must be the problem there.

[waddlesplash]

I fixed that problem in hrev58150.