PROBLEM: mmc_select_hs400es failed, error -110【请注意，邮件由linux-mmc-owner at vger.kernel.org代发】

Milan P. Stanić mps at arvanta.net
Fri Aug 13 12:25:26 PDT 2021 

Hi,

On Mon, 2020-04-20 at 17:15, Milan P. Stanić wrote:
> On Mon, 2020-04-20 at 09:17, Ulf Hansson wrote:
> > On Fri, 17 Apr 2020 at 21:31, Milan P. Stanić <mps at arvanta.net> wrote:
> > > I built chromeOS kernel 4.4.174 and after three days with few
> > > suspend-to-ram and resume mmc driver works fine, i.e. no problem
> > > occured.
> > >
> > > Could someone who know programming mmc drivers look at differences
> > > between this chromeOS kernel (4.4.174) and some of mainline kernels
> > > to find cause of the problem and maybe to create fix or patch to send
> > > for testing.
> > 
> > That delta is more than 4 years of development. I am not sure
> > investigating the delta would make sense, however I leave that to
> > Rock-chips people to decide - or whomever that are willing to help to
> > debug this.
>  
> I think it is not needed to look at full delta from this working
> chromeOS kernel and current mainline but maybe to 5.0 or 5.1 releases.
> 
> But I'm not sure and because I don't know what to look I can only hope
> that rockchip developers will find what is wrong.
> 
> Anyway, I use this rk3399 gru-kevin chromebook with external mmc card
> and it works fine if I don't 'touch' emmc. But is slower than when emmc
> is used for root and home filesystem, significantly, and would be nice
> if someone can find fix or just point me where and what to look.

More than a one year passed but this bug still persist on gru-kevin
chromebook. I'm testing this with every kernel release in hope it will
be fixed.
Now I'm tested it on  5.14.0-rc5

-- 
Kind regards
 
> -- 
> Kind regards
> 
> > Kind regards
> > Uffe
> > 
> > >
> > > --
> > > Regards
> > >
> > > On Tue, 2020-03-31 at 23:40, Milan P. Stanić wrote:
> > > > Hi,
> > > >
> > > > On Mon, 2020-03-30 at 20:19, Ulf Hansson wrote:
> > > > > On Fri, 27 Mar 2020 at 18:14, Milan P. Stanić <mps at arvanta.net> wrote:
> > > > > > Hi,
> > > > > > Anyone looked at this problem?
> > > > > >
> > > > > > Or, is there better url or mailing list where I should send this bug
> > > > > > report?
> > > > >
> > > > > This is the mmc-list and since the rock-chips list was added by Shawn
> > > > > - you have directed your question correctly.
> > > > >
> > > > > The problem is, this isn't a list where everyone can get free support.
> > > > > People may be working on other platforms, for example.
> > > > >
> > > > > The best option for you, is probably to ping Shawn or to reach out to
> > > > > some other Rock-chips people, as it seems like these guys needs to
> > > > > have a closer look.
> > > > >
> > > > > >
> > > > > > Or, could someone tell me what I could try to fix it, which file and
> > > > > > parameters to change?
> > > > >
> > > > > Well, if you can narrow down the problem that is always helpful. So
> > > > > for example, is there any upstream kernel that works - or is it only
> > > > > working through the chrome-os tree (which likely contains vendor
> > > > > specific changes that are not upstream).
> > > >
> > > > Problem is in that the in last 5-6 months chrome-os kernels even don't
> > > > boot, i.e. I only get blank display. I patched it for few releases
> > > > locally but for about 3-4 months even my patch doesn't work.
> > > > Maybe I could find chrome-os kernel about year or two old and try, but
> > > > even then I don't know where to look for this problem.
> > > >
> > > > Other option is to try with mainline kernels from 4.20.x and up one by
> > > > one major release to look on which version this problem started. This
> > > > will take time because problem occurs irregularly, sometimes in a few
> > > > hours but sometimes it works fine for a few days until it appears.
> > > >
> > > > Thank you for pointing me whom to ask and what to try.
> > > >
> > > > --
> > > > Kind regards
> > > >
> > > > > Kind regards
> > > > > Uff
> > > > >
> > > > > >
> > > > > > On Sat, 2020-03-21 at 21:46, Milan P. Stanić wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Thu, 2020-03-19 at 12:28, Robin Murphy wrote:
> > > > > > > > Hi Shawn,
> > > > > > > >
> > > > > > > > On 2020-03-19 3:11 am, Shawn Lin wrote:
> > > > > > > > > Hi Milan
> > > > > > > > >
> > > > > > > > > [+linux-rockchip to see if someone has a Samsung chromebook one plus
> > > > > > > > > and could confirm if it works]
> > > > > > > >
> > > > > > > > FWIW I've also tried suspend on my NanoPC-T4 and seen that the eMMC (also
> > > > > > > > HS400-ES) fails to come back properly on resume (thus resume never completes
> > > > > > > > due to the missing root filesystem). IIRC it might even have been
> > > > > > > > reproducible with suspend-to-idle, but I'd have to double-check that.
> > > > > > >
> > > > > > > I forgot to tell that emmc worked without problem on this machine with
> > > > > > > ChromeOS kernel 4.4.xx downloaded from
> > > > > > > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4
> > > > > > > and with patches from
> > > > > > > https://github.com/archlinuxarm/PKGBUILDs/tree/master/core/linux-gru
> > > > > > > for about two years (iirc).
> > > > > > > Problem started when I switched to mainline kernels, somewhere around
> > > > > > > 5.1.xx
> > > > > > >
> > > > > > > > Robin.
> > > > > > > >
> > > > > > > > > On 2020/3/19 5:49, Milan P. Stanić wrote:
> > > > > > > > > > Hello,
> > > > > > > > > >
> > > > > > > > > > Sorry to annoy again, but could you tell me if I sent this bug report
> > > > > > > > > > to right mail address or I should send it somewhere else.
> > > > > > > > > >
> > > > > > > > > > Also, did I sent bug report correctly or I did some mistakes which
> > > > > > > > > > caused it to be ignored.
> > > > > > > > > >
> > > > > > > > > > -- TIA On Sun, 2020-03-01 at 23:02, Milan P. Stanić wrote:
> > > > > > > > > > > Hello,
> > > > > > > > > > >
> > > > > > > > > > > I'm not native English speaker and I'm self taught in English so sorry
> > > > > > > > > > > if do not write or express correctly. And sorry if I posted bug report
> > > > > > > > > > > to wrong address.
> > > > > > > > > > >
> > > > > > > > > > > I'm running linux 5.6.0-rc3 without any patches on Samsung chromebook
> > > > > > > > > > > one plus, Arm64 rockchip rk3399 based model name:
> > > > > > > > > > > Machine model: Google Kevin
> > > > > > > > > > >
> > > > > > > > > > > I build kernels from upstream git.kernel.org for this machine for some
> > > > > > > > > > > time (iirc, from 5.2.1 and up) but I'm getting error messages in kernel
> > > > > > > > > > > after machine resumes from suspend-to-ram.
> > > > > > > > >
> > > > > > > > > It sounds to me suspend-to-ram never works for this machine, at least
> > > > > > > > > since 5.2.1. Am I right?
> > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > excerpt from dmesg output:
> > > > > > > > > > > -----------------------------------------------------------------------
> > > > > > > > > > > Restarting tasks ... done.
> > > > > > > > > > > PM: suspend exit
> > > > > > > > > > > mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz,
> > > > > > > > > > > actual 400000HZ div = 0)
> > > > > > > > > > > mmc1: mmc_select_hs400es failed, error -110
> > > > > > > > > > > mmc1: error -110 doing runtime resume
> > > > > > > > > > > mmc1: Got data interrupt 0x00000002 even though no data
> > > > > > > > > > > operation was in progress.
> > > > > > > > > > > mmc1: sdhci: ============ SDHCI REGISTER DUMP ===========
> > > > > > > > > > > mmc1: sdhci: Sys addr:  0x00000008 | Version:  0x00001002
> > > > > > > > > > > mmc1: sdhci: Blk size:  0x00007200 | Blk cnt:  0x00000008
> > > > > > > > > > > mmc1: sdhci: Argument:  0x00000000 | Trn mode: 0x00000023
> > > > > > > > > > > mmc1: sdhci: Present:   0x1fff0001 | Host ctl: 0x00000035
> > > > > > > > > > > mmc1: sdhci: Power:     0x0000000b | Blk gap:  0x00000080
> > > > > > > > > > > mmc1: sdhci: Wake-up:   0x00000000 | Clock:    0x0000bc07
> > > > > > > > > > > mmc1: sdhci: Timeout:   0x0000000d | Int stat: 0x00000000
> > > > > > > > > > > mmc1: sdhci: Int enab:  0x03ff000b | Sig enab: 0x03ff000b
> > > > > > > > > > > mmc1: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
> > > > > > > > > > > mmc1: sdhci: Caps:      0x44edc880 | Caps_1:   0x801020f7
> > > > > > > > > > > mmc1: sdhci: Cmd:       0x00000c1a | Max curr: 0x00000000
> > > > > > > > > > > mmc1: sdhci: Resp[0]:   0x00000000 | Resp[1]:  0x373300bd
> > > > > > > > > > > mmc1: sdhci: Resp[2]:   0x35303030 | Resp[3]:  0x00000000
> > > > > > > > > > > mmc1: sdhci: Host ctl2: 0x00000000
> > > > > > > > > > > mmc1: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0xed41e200
> > > > > > > > > > > -----------------------------------------------------------------------
> > > > > > > > > > >
> > > > > > > > > > > I invoke suspend-to-ram by `echo mem > /sys/power/state` from ACPI power
> > > > > > > > > > > and LID button handlers.
> > > > > > > > > > >
> > > > > > > > > > > This only happens when I boot and use internal emmc card and never when
> > > > > > > > > > > boot and use external mmc card.
> > > > > > > > > > >
> > > > > > > > > > > If suspend-to-ram is not invoked (machine is always in normal state)
> > > > > > > > > > > this problem never happen (or I missed it somehow).
> > > > > > > > > > >
> > > > > > > > > > > I'm attaching kernel .config (file config-5.6.0-rc3-1-gru.conf) which
> > > > > > > > > > > use to build kernel, output of the `awk -f scripts/ver_linux` as file
> > > > > > > > > > > ver_linux.txt and  output of dmesg as file mmc-err.txt (from which I
> > > > > > > > > > > deleted wifi connection logs).
> > > > > > > > > > >
> > > > > > > > > > > Sorry if I did something bad or wrong with this bug report, I don't have
> > > > > > > > > > > much experience with bug reporting, especially for kernel.
> > > > > > > > > > >
> > > > > > > > > > > I'm ready to send you more data, and investigate this more, apply
> > > > > > > > > > > patches and rebuild kernel or whatever you ask me (of course if my
> > > > > > > > > > > understanding and knowledge is enough for this job).
> > > > > > > > > > >
> > > > > > > > > > > Thank in advance
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Kind regards
> > > > > > > > > > >
> > > > > > > > > > [...]
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > Linux-rockchip mailing list
> > > > > > > > > Linux-rockchip at lists.infradead.org
> > > > > > > > > http://lists.infradead.org/mailman/listinfo/linux-rockchip

More information about the Linux-rockchip mailing list