linux-kernel - Re: orion-nand: uncorrectable ECC error on v5.10-rc6

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: <20201202093157.4fa6998f@xps13>
Date:   Wed, 2 Dec 2020 09:31:57 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Chris Packham <Chris.Packham@...iedtelesis.co.nz>
Cc:     "richard@....at" <richard@....at>, Vignesh R <vigneshr@...com>,
        "boris.brezillon@...labora.com" <boris.brezillon@...labora.com>,
        "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: orion-nand: uncorrectable ECC error on v5.10-rc6

Hi Chris,

Chris Packham <Chris.Packham@...iedtelesis.co.nz> wrote on Wed, 2 Dec
2020 08:23:13 +0000:

> Hi Miquel,
> 
> On 2/12/20 8:59 pm, Miquel Raynal wrote:
> > Hi Chris,
> >
> > Chris Packham <Chris.Packham@...iedtelesis.co.nz> wrote on Wed, 2 Dec
> > 2020 07:47:32 +0000:
> >  
> >> Hi,
> >>
> >> I've just booted v5.10-rc6 on a kirkwood based board (which uses the
> >> orion-nand driver) and I get the following errors reported. I haven't
> >> started bisecting yet but v5.7.19 mounts the nand flash without any issue.
> >>
> >> ubi0: attaching mtd0
> >> __nand_correct_data: uncorrectable ECC error
> >> ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes
> >> from PEB 0:0, read only 64 bytes, retry
> >> __nand_correct_data: uncorrectable ECC error
> >> ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes
> >> from PEB 0:0, read only 64 bytes, retry
> >> __nand_correct_data: uncorrectable ECC error
> >> ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes
> >> from PEB 0:0, read only 64 bytes, retry
> >> __nand_correct_data: uncorrectable ECC error
> >> ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes
> >> from PEB 0:0, read 64 bytes
> >> CPU: 0 PID: 101 Comm: ubiattach Not tainted 5.10.0-rc6+ #1
> >> Hardware name: Marvell Kirkwood (Flattened Device Tree)
> >> [<8010ca64>] (unwind_backtrace) from [<80109bd0>] (show_stack+0x10/0x14)
> >> [<80109bd0>] (show_stack) from [<8045f10c>] (ubi_io_read+0x184/0x304)
> >> [<8045f10c>] (ubi_io_read) from [<8045f4ac>] (ubi_io_read_ec_hdr+0x44/0x240)
> >> [<8045f4ac>] (ubi_io_read_ec_hdr) from [<80464db0>]
> >> (ubi_attach+0x178/0x15fc)
> >> [<80464db0>] (ubi_attach) from [<80458d8c>] (ubi_attach_mtd_dev+0x538/0xb48)
> >> [<80458d8c>] (ubi_attach_mtd_dev) from [<8045a114>]
> >> (ctrl_cdev_ioctl+0x170/0x1e0)
> >> [<8045a114>] (ctrl_cdev_ioctl) from [<80203094>] (sys_ioctl+0x1f8/0x990)
> >> [<80203094>] (sys_ioctl) from [<80100060>] (ret_fast_syscall+0x0/0x50)
> >> Exception stack(0x87633fa8 to 0x87633ff0)
> >> 3fa0:                   00000003 7e9b0c30 00000003 40186f40 7e9b0c30
> >> 00000000
> >> 3fc0: 00000003 7e9b0c30 000148f8 00000036 00014770 00013f90 76f3dfa4
> >> 00000000
> >> 3fe0: 76e936f0 7e9b0c1c 00011f68 76e936fc  
> > I recently contributed a pile of fixes to ensure DT parsing was not
> > broken and this applies to Orion. Can you please check
> >
> > mtd: rawnand: orion: Move the ECC initialization to ->attach_chip()  
> That looks to be it. In Linus's tree commit 76dc2bfc2e1b ("Merge tag 
> 'mtd/fixes-for-5.10-rc6' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux") seems to be 
> the difference between working and not working.
> > And tell me if you see something wrong there? I assumed this driver was
> > not supporting on host ECC engines and only soft Hamming was used, is
> > this assumption wrong?  
> 
> Our dts has
> 
>          nand-ecc-mode = "soft";
>          nand-ecc-algo = "bch";
>          nand-on-flash-bbt;
> 

I assumed Hamming was the only possible algorithm, this is the error.

I have several drivers in this case then.

We need to default to Hamming but let the user decide then. Can you try
something like the below change please?


Thanks,
Miquèl


---8<---

Author: Miquel Raynal <miquel.raynal@...tlin.com>
Date:   Wed Dec 2 09:31:14 2020 +0100

    mtd: rawnand: orion: Fix soft ECC algo selection
    
    Signed-off-by: Miquel Raynal <miquel.raynal@...tlin.com>

diff --git a/drivers/mtd/nand/raw/orion_nand.c b/drivers/mtd/nand/raw/orion_nand.c
index e3bb65fd3ab2..66211c9311d2 100644
--- a/drivers/mtd/nand/raw/orion_nand.c
+++ b/drivers/mtd/nand/raw/orion_nand.c
@@ -86,7 +86,9 @@ static void orion_nand_read_buf(struct nand_chip *chip, uint8_t *buf, int len)
 static int orion_nand_attach_chip(struct nand_chip *chip)
 {
        chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;
-       chip->ecc.algo = NAND_ECC_ALGO_HAMMING;
+
+       if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN)
+               chip->ecc.algo = NAND_ECC_ALGO_HAMMING;
 
        return 0;
 }