lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA+hA=RajAB8nOHz2JnxHXdnnJrGhqNLEgsRER0-3N-7ghOj2g@mail.gmail.com>
Date:   Tue, 10 Jan 2017 23:25:00 +0800
From:   Dong Aisheng <dongas86@...il.com>
To:     Jagan Teki <jagan@...nedev.com>
Cc:     Clemens Gruber <clemens.gruber@...ruber.com>,
        Shawn Lin <shawn.lin@...k-chips.com>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Dong Aisheng <aisheng.dong@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed

On Tue, Jan 10, 2017 at 6:25 AM, Jagan Teki <jagan@...nedev.com> wrote:
> On Fri, Jan 6, 2017 at 5:07 PM, Clemens Gruber
> <clemens.gruber@...ruber.com> wrote:
>> On Fri, Jan 06, 2017 at 10:54:35AM +0800, Shawn Lin wrote:
>>> On 2017/1/6 8:41, Clemens Gruber wrote:
>>> > Hi,
>>> >
>>> > with the current mainline 4.10-rc2 kernel, I can no longer boot from
>>> > the eMMC on my i.MX6Q board.
>>> >
>>> > Details:
>>> > The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
>>> > eMMC 4.41 features and we did not implement voltage switching from 3.3V
>>> > to 1.8V or lower, I did add no-1-8-v; (but none of the mmc-ddr or mmc-hs
>>> > options) to the device tree. The bus-width is 8.
>>> >
>>> > With 4.9 the board booted fine, now with the current mainline 4.10 tree,
>>> > I get the following (repeating) errors at boot:
>>> >
>>> > [    4.326834] Waiting for root device /dev/mmcblk0p2...
>>> > [   14.563861] mmc0: Timeout waiting for hardware cmd interrupt.
>>> > [   14.569619] sdhci: =========== REGISTER DUMP (mmc0)===========
>>> > [   14.575461] sdhci: Sys addr: 0x4e726000 | Version:  0x00000002
>>> > [   14.581300] sdhci: Blk size: 0x00000200 | Blk cnt:  0x00000001
>>> > [   14.587140] sdhci: Argument: 0x00010000 | Trn mode: 0x00000013
>>> > [   14.592979] sdhci: Present:  0x01fd8009 | Host ctl: 0x00000031
>>> > [   14.598816] sdhci: Power:    0x00000002 | Blk gap:  0x00000080
>>> > [   14.604654] sdhci: Wake-up:  0x00000008 | Clock:    0x0000001f
>>> > [   14.610493] sdhci: Timeout:  0x0000008f | Int stat: 0x00000000
>>> > [   14.616332] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>>> > [   14.622168] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000003
>>> > [   14.628007] sdhci: Caps:     0x07eb0000 | Caps_1:   0x0000a007
>>> > [   14.633845] sdhci: Cmd:      0x00000d1a | Max curr: 0x00ffffff
>>> > [   14.639682] sdhci: Host ctl2: 0x00000000
>>> > [   14.643611] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x4e6f7208
>>> > [   14.649447] sdhci: ===========================================
>>> >
>>> > This repeats a few times, then more information is shown at the bottom:
>>> >
>>> > [   86.893859] mmc0: Timeout waiting for hardware cmd interrupt.
>>> > [   86.899615] sdhci: =========== REGISTER DUMP (mmc0)===========
>>> > [   86.905453] sdhci: Sys addr: 0x00000000 | Version:  0x00000002
>>> > [   86.911291] sdhci: Blk size: 0x00000200 | Blk cnt:  0x00000001
>>> > [   86.917129] sdhci: Argument: 0x00010000 | Trn mode: 0x00000013
>>> > [   86.922967] sdhci: Present:  0x01fd8009 | Host ctl: 0x00000031
>>> > [   86.928804] sdhci: Power:    0x00000002 | Blk gap:  0x00000080
>>> > [   86.934642] sdhci: Wake-up:  0x00000008 | Clock:    0x0000001f
>>> > [   86.940479] sdhci: Timeout:  0x0000008f | Int stat: 0x00000000
>>> > [   86.946316] sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
>>> > [   86.952154] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000003
>>> > [   86.957992] sdhci: Caps:     0x07eb0000 | Caps_1:   0x0000a007
>>> > [   86.963830] sdhci: Cmd:      0x00000d1a | Max curr: 0x00ffffff
>>> > [   86.969668] sdhci: Host ctl2: 0x00000000
>>> > [   86.973596] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000000
>>> > [   86.979433] sdhci: ===========================================
>>> > [   86.986356] mmc0: switch to bus width 8 ddr failed
>>> > [   86.991163] mmc0: error -110 whilst initialising MMC card
>>> > [   97.773859] mmc0: Timeout waiting for hardware cmd interrupt.
>>> >
>>> > --
>>> >
>>> > After looking through the latest commits to mmc/core, I found the
>>> > culprit:
>>> > Commit e173f8911f091fa50ccf8cc1fa316dd5569bc470 ("mmc: core: Update
>>> > CMD13 polling policy when switch to HS DDR mode")
>>> >
>>> > Reverting it fixes the problem. But I am unsure if that's the right
>>> > course of action?
>>> >
>>> > Feel free to send me patches for testing!
>>> >
>>>
>>> I just look into both of sdhci and sdhci-esdhc-imx again, and seems the
>>> code miss a bit, so could you also try this one?
>>>
>>> drivers/mmc/core/mmc_ops.c
>>> @@ -486,7 +486,8 @@ static int mmc_poll_for_busy(struct mmc_card *card,
>>> unsigned int timeout_ms,
>>>                         busy = host->ops->card_busy(host);
>>>                 } else {
>>>                         err = mmc_send_status(card, &status);
>>> -                       if (retry_crc_err && err == -EILSEQ) {
>>> +                       if (retry_crc_err && (err == -EILSEQ ||
>>> +                                               err == -ETIMEDOUT)) {
>>>                                 busy = true;
>>>                         } else if (err) {
>>>                                 return err;
>>>
>>
>> Hi,
>>
>> this patch (alone) does not solve the problem. The error message is the
>> same as before.
>>
>> But applying both your first patch and this one does work. Is this one
>> beneficial anyway, even if it does not fix my problem?
>
> Able to detect the eMMC, but getting kernel panic while formatting the
> disk, (even remove the mmc_ops change)
>
> Log:
> ----
> Disk /dev/mmcblk1: 3791 MB, 3791650816 bytes
> 4 heads, 16 sectors/track, 115712 cylinders
> Units = cylinders of 64 * 512 = 32768 bytes
>
>         Device Boot      Start         End      Blocks  Id System
> /dev/mmcblk1p1               1      115712     3702776  83 Linux
>
>
> Maximum filesystem blocks=4194304
> 29 block groups
> 32768 blocks per group, 32768 fragments per group
> 7984 inodes per group
> Superblock backups stored on blocks:
>         32768, 98304, 163840, 229376, 294912, 819200, 884736
> [  256.769236] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x00000004
> [  256.769236]
> [  256.778779] ---[ end Kernel panic - not syncing: Attempted to kill
> init! exitcode=0x00000004
> [  256.778779]
>

Did not see MMC errors.
You'd better paste more log.

Regards
Dong Aisheng

> Jagan.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ