[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <79b81748-8508-414f-c08a-c99cb4ae4b2a@amlogic.com>
Date: Fri, 29 Mar 2019 15:44:30 +0800
From: Liang Yang <liang.yang@...ogic.com>
To: Martin Blumenstingl <martin.blumenstingl@...glemail.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 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.
Powered by blists - more mailing lists