[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFBinCCSkVGp_iWKf=o=7UGuDUWxyLPGdrqGy_P-HPuEJiU1zQ@mail.gmail.com>
Date: Fri, 5 Apr 2019 06:30:51 +0200
From: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To: Liang Yang <liang.yang@...ogic.com>
Cc: Matthew Wilcox <willy@...radead.org>, mhocko@...e.com,
linux@...linux.org.uk, linux-kernel@...r.kernel.org,
rppt@...ux.ibm.com, linux-mm@...ck.org,
linux-mtd@...ts.infradead.org, linux-amlogic@...ts.infradead.org,
akpm@...ux-foundation.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: 32-bit Amlogic (ARM) SoC: kernel BUG in kfree()
Hi Liang,
On Fri, Mar 29, 2019 at 8:44 AM Liang Yang <liang.yang@...ogic.com> wrote:
>
> Hi Martin,
>
> On 2019/3/29 2:03, Martin Blumenstingl wrote:
> > Hi Liang,
> [......]
> >> I don't think it is caused by a different NAND type, but i have followed
> >> the some test on my GXL platform. we can see the result from the
> >> attachment. By the way, i don't find any information about this on meson
> >> NFC datasheet, so i will ask our VLSI.
> >> Martin, May you reproduce it with the new patch on meson8b platform ? I
> >> need a more clear and easier compared log like gxl.txt. Thanks.
> > your gxl.txt is great, finally I can also compare my own results with
> > something that works for you!
> > in my results (see attachment) the "DATA_IN [256 B, force 8-bit]"
> > instructions result in a different info buffer output.
> > does this make any sense to you?
> >
> I have asked our VLSI designer for explanation or simulation result by
> an e-mail. Thanks.
do you have any update on this?
Martin
Powered by blists - more mailing lists