Slow boot and SDHCI errors on some Bay Trail models with RW_LEGACY firmware

[reynhout]

Hundreds of lines of messages like the following:

[   31.393210] mmc2: Reset 0x4 never completed.
[   31.394561] sdhci: =========== REGISTER DUMP (mmc2)===========
[   31.395947] sdhci: Sys addr: 0xffffffff | Version:  0x0000ffff
[   31.397347] sdhci: Blk size: 0x0000ffff | Blk cnt:  0x0000ffff
[   31.398745] sdhci: Argument: 0xffffffff | Trn mode: 0x0000ffff
[   31.400142] sdhci: Present:  0xffffffff | Host ctl: 0x000000ff
[   31.401540] sdhci: Power:    0x000000ff | Blk gap:  0x000000ff
[   31.402941] sdhci: Wake-up:  0x000000ff | Clock:    0x0000ffff
[   31.404338] sdhci: Timeout:  0x000000ff | Int stat: 0xffffffff
[   31.405732] sdhci: Int enab: 0xffffffff | Sig enab: 0xffffffff
[   31.407124] sdhci: AC12 err: 0x0000ffff | Slot int: 0x0000ffff
[   31.408519] sdhci: Caps:     0xffffffff | Caps_1:   0xffffffff
[   31.409908] sdhci: Cmd:      0x0000ffff | Max curr: 0xffffffff
[   31.411281] sdhci: Host ctl2: 0x0000ffff
[   31.412636] sdhci: ADMA Err: 0xffffffff | ADMA Ptr: 0xffffffff
[   31.413999] sdhci: ===========================================
[   31.415385] mmcblk2: error -5 sending status command, aborting
[   31.416783] blk_update_request: I/O error, dev mmcblk2, sector 4476928
[   31.418184] Buffer I/O error on dev mmcblk2p3, logical block 0, async page read
[   31.429643] mmc2: Controller never released inhibit bit(s).

Reported on CANDY and NINJA.

Side effect seems to be slow booting (between 5 and 30 additional seconds).

On some models, including CANDY and NINJA, stock ChromeOS firmware leaves the SD/eMMC devices in PCI mode (vs ACPI mode).

Problem does not occur with full firmware or BOOT_STUB.

[elitak]

I get the same thing on BANJO, and have no way of accessing mmcblk0 when booted via RW_LEGACY. I don't know what to try besides sdhci-acpi and sdhci-pci, in terms of modules.

Removing write-protect and trying the other roms isn't really an option for me. Is there some chromium patch to sdhci-acpi I can apply to mainline to fix this?

[sinpai]

Same on my Candy device. I've tried installing on SSD, along with ChromeOS - have no luck to boot it. When i've installed it on SD card - I can boot it 1 of 3 times. But every time a huge amount of these ("[ 31.393210] mmc2: Reset 0x4 never completed. / [ 31.394561] sdhci: =========== REGISTER DUMP (mmc2)===========") messages appear. 2 of 3 times name of partition changes and grub couldn't find partition. For example, in GRUB - "root=/dev/mmcblk0p7", but blkid command output states that needed partition have name "/dev/mmcblk1p7". Another time it can also change to "mmcblk2p7".

I've also tried to remove write-protect, but nothing changed for real.

[reynhout]

It looks like the device number (0,1,2) is sometimes changing between boots. Devices are assigned a number based on the order that the kernel sees them at boot time, so there are no guarantees...but it's odd that we've never seen the issue on other models, or on these models previously.

The issue might be fixable by specifying the storage device by UUID instead of by device number/path. There are two places to update: /etc/fstab, and GRUB config, e.g.:

• /etc/fstab UUID=6a249da6-2713-41fc-867f-3e62db5239c0 / ext4 errors=remount-ro 0 1
• GRUB config There are multiple instances to fix, all in /boot/grub/grub.cfg. It might be easier to change the config from the GRUB shell (Esc before booting, then edit the live config), and then rewriting grub.cfg after booting successfully. I am not completely certain this would be adequate though. :(

To find the correct UUID for your filesystem root, after successfully booting:

• sudo grub-probe -t fs_uuid /boot/grub, or
• sudo blkid -s UUID -o value $(findmnt -n -o SOURCE /)

If normal boot does not succeed, you can boot from ISO or ChromeOS and run:

• sudo blkid -s UUID -o value $GALLIUMOS_ROOT

Replace $GALLIUMOS_ROOT with the partition of your GalliumOS installation. You'll need to find it, and it will depend on the device number, but (on Bay Trail, dual-booting) it will be something like /dev/mmcblk2p7.

---

These are just ideas/notes that might be useful. If I am able to repro the problem, I'll be able to figure out a solution...but for now I can only guess.

(comment copied from https://www.reddit.com/r/GalliumOS/comments/6dp1h9/cannot_boot_into_galliumos_after_installing_via/)

[AdrianBWeissman]

Has anyone had any success in fixing this issue ? I have the exact same problem.

[marc-h38]

This looks different but just in case: https://chromium-review.googlesource.com/c/201790/6/drivers/mmc/host/sdhci-acpi.c CHROMIUM: mmc: shdci: Prevent CPU in deeper Cx states when data transferring

Newer UPSTREAM in chromeos-4.4: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a3043ecef71f5b8%5E%21/#F1 mmc: sdhci-acpi: Reduce Baytrail eMMC/SD/SDIO hangs

Older, both in sdhci-acpi.c and sdhci-pci.c: https://chromium-review.googlesource.com/c/292483 (chromeos-3.18 / BSW / SKL)

[tolidano]

I'm having this issue and posted about it here with everything I know about the issue right now: https://www.reddit.com/r/GalliumOS/comments/8p2kc7/boot_issues_with_galliumos/ Any assistance would be appreciated.

[DavidVentura]

I just faced the same issue - replacing /dev/mmcblk0p7 with UUID=... on both /etc/fstab and /boot/grub/grub.cfg doesn't help.

I get a lot of sdhci errors followed by (quite a few):

blk_update_request: I/O error, dev mmcblk2, sector 11878****

[DarkloveNonServium]

i know this is old but i found a solution as it happened to me yesterday. the solution isnt marked specifically for this issue but i applied it and iit solved the problem. reynhout is who led me to the solution with what he posted. i was thinking along thesame lines and i kept trying to change the disk root too mmcblk01/2/3 etc and it always changed back to a diefferent one. this solution does what reynhout was talking about in UUID method of mounting the root. and it installs on bothe the parent and child disk so when it boots or switches disks its unaffected. good luck to all

https://jrs-s.net/2017/12/05/boot-rescue-for-galliumos-chrx-on-chromebooks/

Boot rescue for GalliumOS / chrx on Chromebooks Since acquiring a small fleet of HP Chromebooks for use in network testing, I’ve discovered that once in a blue moon, one of them that’s lost power while running will have trashed its Linux boot configuration – in which case it hangs at the SeaBIOS “Booting from Hard Disk…” black screen indefinitely.

The fix is obscure but doesn’t take long. What you need to do is boot into ChromeOS, but don’t log in. Instead, press ctrl-alt-F2 (probably ctrl-alt-right-arrow on most Chromebook keyboards) to get a bash login. Log in as chronos, no password. Sudo -s to become root. Now run the “mount” command, with no arguments – you should see a few partitions from your system disk mounted; what the device name is can vary from Chromebook to Chromebook. Mine is /dev/mmcblk0, so partitions look like /dev/mmcblk0p7.

Standard chrx disk layouts that preserve ChromeOS should have the Linux partition as p7 on the system disk; so you’ll be looking at something like /dev/sda7 or /dev/mmcblk0p7. You’re going to make a temp directory, mount that Linux partition on the temp directory, then chroot inside it so that you can update the bootloader. Adjust that first mount command as necessary for your system, and you’re off to the races:

mkdir /tmp/a

mount /dev/mmcblk0p7 /tmp/a mount -o bind /proc /tmp/a/proc mount -o bind /dev /tmp/a/dev mount -o bind /dev/pts /tmp/a/dev/pts mount -o bind /sys /tmp/a/sys mount -o bind /run /tmp/a/run

chroot /tmp/a /bin/bash

dpkg-reconfigure grub-pc That’s it. dpkg-reconfigure will ask you a few questions, including one about the boot command line – which will come up blank, and which you can leave blank. Aside from that, enter your way through; you’re done in a few seconds, after which exit exit exit your way out, reboot, and your Linux installation will boot again!