search

GalliumOS / galliumos-distro

Docs, issues, and artwork sources for GalliumOS
https://galliumos.org/
GNU General Public License v2.0
348 stars 11 forks source link

mmc1 timeout prevents suspend on cave #335

Open ifuller1 opened 7 years ago

ifuller1 commented 7 years ago

Issue

  1. Your Chromebook/Chromebox model hardware ID: CAVE
  2. Your firmware: stock/factory, MattDevo, CoolStar, John Lewis, or other: Stock
  3. Your installation method (ISO or chrx) and whether you're running a nightly build: Chrx
  4. A detailed description of the problem, and steps to reproduce it:

Current behaviour:

  1. Closing the lid or select 'suspend' in the power menu
  2. wifi is disabled
  3. laptop does not suspend
  4. dmesg contains mmc1: Timeout waiting for hardware interrupt

Expected:

  1. Closing the lid or selecting 'suspend' in the power menu
  2. Laptop is suspended
reynhout commented 7 years ago

Thank you for the detailed info!

There's a similar report in #332. Does that description match your experience?

ifuller1 commented 7 years ago

Hey @reynhout - I think you linked back to this issue by accident?

reynhout commented 7 years ago

Oops, quite right. I meant #332. :) Fixed above.

ifuller1 commented 7 years ago

Hey @reynhout - I don't think so. I don't think it ever suspends (I've been sat using it for a good while afterwards trying to debug the issue and it never suspended). Also - no mention of the mmc1 timeout which I'm assuming is the blocking issue in my case?

irwineffect commented 7 years ago

On my machine I also get the same message in my dmesg, however it occurs before I even try to suspend, about once every 10 seconds.

ifuller1 commented 7 years ago

Hey @reynhout - apologies, it does suspend eventually... I forgot to shutdown and it slept! :)

I did an EC reset as I was getting reboots after sleep (in ChromeOS) and it all seems more healthy now ¯_(ツ)_/¯

:+1:

irwineffect commented 7 years ago

@ifuller1, are you saying it's properly suspending now (without the long delay)?

ifuller1 commented 7 years ago

No sorry - the long delay exists but it does eventually shutdown (5 minutes maybe).

The EC reset prevented the device rebooting entirely after sleep - which I'd assumed was related to the sleep issue, but seems was not.

jmburges commented 7 years ago

I have this issues as well. I'm on a Asus Chromebook Flip 302A. I pretty much can't suspend. Sometimes it works I guess but usually after a ton of minutes of waiting. Here is the dmesg output that keeps repeating:

[  381.929435] mmc1: Timeout waiting for hardware cmd interrupt.
[  381.929452] sdhci: =========== REGISTER DUMP (mmc1)===========
[  381.929466] sdhci: Sys addr: 0x00000000 | Version:  0x00001002
[  381.929478] sdhci: Blk size: 0x00000000 | Blk cnt:  0x00000000
[  381.929489] sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
[  381.929497] sdhci: Present:  0x000a0001 | Host ctl: 0x00000001
[  381.929508] sdhci: Power:    0x0000000e | Blk gap:  0x00000080
[  381.929519] sdhci: Wake-up:  0x00000000 | Clock:    0x0000e8c7
[  381.929530] sdhci: Timeout:  0x00000000 | Int stat: 0x00000000
[  381.929541] sdhci: Int enab: 0x00ff0003 | Sig enab: 0x00ff0003
[  381.929552] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
[  381.929564] sdhci: Caps:     0x7568c881 | Caps_1:   0x00000807
[  381.929575] sdhci: Cmd:      0x00000502 | Max curr: 0x00000000
[  381.929584] sdhci: Host ctl2: 0x00000000
[  381.929597] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x0000000000000000
ghost commented 6 years ago

I am having the same issue on CAVE. I first identified the issue after installing the latest GalliumOS ISO and applying all updates at the time of this writing.

I performed a reinstallation of Gallium and did not update to try to weed out issues. This yielded the same mmc1 timeouts and suspend failures. This issue also seems to prevent proper restart/shut down from the software.

caladd commented 6 years ago

My CAVE chromebook (Asus Flip c302) is also showing the mmc1 timeouts every 10 seconds:

[ 1309.632559] mmc1: Timeout waiting for hardware cmd interrupt.
[ 1309.632571] sdhci: =========== REGISTER DUMP (mmc1)===========
[ 1309.632584] sdhci: Sys addr: 0x00000000 | Version:  0x00001002
[ 1309.632593] sdhci: Blk size: 0x00000000 | Blk cnt:  0x00000000
[ 1309.632598] sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
[ 1309.632603] sdhci: Present:  0x000a0001 | Host ctl: 0x00000001
[ 1309.632609] sdhci: Power:    0x0000000e | Blk gap:  0x00000080
[ 1309.632614] sdhci: Wake-up:  0x00000000 | Clock:    0x0000e8c7
[ 1309.632619] sdhci: Timeout:  0x00000000 | Int stat: 0x00000000
[ 1309.632624] sdhci: Int enab: 0x00ff0003 | Sig enab: 0x00ff0003
[ 1309.632629] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
[ 1309.632635] sdhci: Caps:     0x7568c881 | Caps_1:   0x00000807
[ 1309.632640] sdhci: Cmd:      0x00000502 | Max curr: 0x00000000
[ 1309.632644] sdhci: Host ctl2: 0x00000000
[ 1309.632651] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x0000000000000000
[ 1309.632653] sdhci: ===========================================

I haven't noticed any suspend issues. My Gallium install was made off of an SD card using the galliumos-skylake-2.1.iso, using the RW_LEGACY firmware from MrChromebox, and wiping the entire hard drive.

reynhout commented 6 years ago

Are you seeing this issue on the stable kernel? I've seen it on the test kernels (currently 4.14.15, but 4.12.x also IIRC).

Also curious: internal storage should be mmc0, I think. All reports here, and my repro example, are for timeouts on mmc1, which does not exist on my test device.

reynhout commented 6 years ago

A comment on #332 indicates that suspend works normally, and the timeout errors do not occur if there's a SD card installed (which would be mmc1, by all usual expectations). I am able to repro this on CAROLINE. Now we just have to find out why the kernel thinks it should pay attention to a non-existent device... :(

caladd commented 6 years ago

My kernel is the stock one from stable: 4.8.17-galliumos #1 SMP PREEMPT galliumos4 Thu Feb 23 02:27:28 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

mmc0 is the internal drive on CAVE. mmc1 is the microsd card slot. When I put a card in it, the timeout errors go away. I pop it out, and they come back.

flantel commented 6 years ago

I am seeing this as well on my CAVE Flip 302. It appears to only have started when I changed to test and the 4.14.29 kernel. It also appears to cause a lock-up if screen left open and it then suspends.

jdeorian commented 5 years ago

I am having this issue on my C302, as well. I have an SD card installed and it does not resolve.

Edit: SD card, not SSD

reynhout commented 5 years ago

@jdeorian Not an SSD, an SD card. Not tested on CAVE, but works reliably on CAROLINE and I'd expect them to be the same.

jdeorian commented 5 years ago

Good catch - it's a typo. Yes, I have an SD card installed and it has not resolved the issue.

Fixing above to avoid confusion for anyone looking in the future.

reynhout commented 5 years ago

@jdeorian I figured as much, but was hopeful. :)

So when you have the SD card installed, what device does it show up as? (check with lsblk, I'd expect it to be mmc1). And what device are the error messages complaining about (on CAROLINE, it's also mmc1, and the error goes away when the media is installed).

jdeorian commented 5 years ago

@reynhout

My SD card shows up as mmcblk1. I don't see any complaint when I try to suspend. Should I be looking at a log file or some kind of verbose Suspend? For me, it just hangs interminably.