Hi,
On 2022/03/09 1:23, Ahmad Fatoum wrote:
Hello Tokunori-san,
On 08.03.22 17:13, Tokunori Ikegami wrote:
Hi Ahmad-san,
On 2022/03/08 18:44, Ahmad Fatoum wrote:
Hello Tokunori,
On 06.03.22 16:49, Tokunori Ikegami wrote:
Hi,
On 2022/03/04 20:11, Ahmad Fatoum wrote:
Hello Tokunori-san,
O
Hello Tokunori-san,
On 08.03.22 17:13, Tokunori Ikegami wrote:
> Hi Ahmad-san,
>
> On 2022/03/08 18:44, Ahmad Fatoum wrote:
>> Hello Tokunori,
>>
>> On 06.03.22 16:49, Tokunori Ikegami wrote:
>>> Hi,
>>>
>>> On 2022/03/04 20:11, Ahmad Fatoum wrote:
Hello Tokunori-san,
On 20.02.22 1
Hi Ahmad-san,
On 2022/03/08 18:44, Ahmad Fatoum wrote:
Hello Tokunori,
On 06.03.22 16:49, Tokunori Ikegami wrote:
Hi,
On 2022/03/04 20:11, Ahmad Fatoum wrote:
Hello Tokunori-san,
On 20.02.22 13:22, Tokunori Ikegami wrote:
Hi Ahmad-san,
Could you please try the version 2 patch attached for
Hello Tokunori,
On 06.03.22 16:49, Tokunori Ikegami wrote:
> Hi,
>
> On 2022/03/04 20:11, Ahmad Fatoum wrote:
>> Hello Tokunori-san,
>>
>> On 20.02.22 13:22, Tokunori Ikegami wrote:
>>> Hi Ahmad-san,
>>>
>>> Could you please try the version 2 patch attached for the error case?
>>> This version is
Hi,
On 2022/03/04 20:11, Ahmad Fatoum wrote:
Hello Tokunori-san,
On 20.02.22 13:22, Tokunori Ikegami wrote:
Hi Ahmad-san,
Could you please try the version 2 patch attached for the error case?
This version is to check the DQ true data 0xFF by chip_good().
I had a similar patch locally as well
Hello Tokunori-san,
On 20.02.22 13:22, Tokunori Ikegami wrote:
> Hi Ahmad-san,
>
> Could you please try the version 2 patch attached for the error case?
> This version is to check the DQ true data 0xFF by chip_good().
I had a similar patch locally as well at first. I just tested yours
and I can'
Hi Ahmad-san,
Could you please try the version 2 patch attached for the error case?
This version is to check the DQ true data 0xFF by chip_good().
But I am not sure if this works or not since the error is possible to be
caused by Hi-Z 0xff on floating bus or etc.
On 2022/02/15 3:46, Tokunori I
Hi Ahmad-san,
On 2022/02/15 1:22, Ahmad Fatoum wrote:
Hello Tokunori-san,
On 13.02.22 17:47, Tokunori Ikegami wrote:
Hi Ahmad-san,
Thanks for your confirmations. Sorry for late to reply.
No worries. I appreciate you taking the time.
Could you please try the patch attached to disable the ch
Hello Tokunori-san,
On 13.02.22 17:47, Tokunori Ikegami wrote:
> Hi Ahmad-san,
>
> Thanks for your confirmations. Sorry for late to reply.
No worries. I appreciate you taking the time.
> Could you please try the patch attached to disable the chip_good() change as
> before?
> I think this shoul
Hi Ahmad-san,
Thanks for your confirmations. Sorry for late to reply.
Could you please try the patch attached to disable the chip_good()
change as before?
I think this should work for S29GL964N since the chip_ready() is used
and works as mentioned.
On 2022/02/07 23:28, Ahmad Fatoum wrote:
H
Hello Tokunori-san,
On 29.01.22 19:01, Tokunori Ikegami wrote:
> Hi Ahmad-san,
>
> Thanks for your investigation.
>
>> The issue is still there with #define FORCE_WORD_WRITE 1:
>>
>> jffs2: Write clean marker to block at 0x000a failed: -5
>> MTD do_write_oneword_once(): software timeou
Hi Ahmad-san,
Thanks for your investigation.
The issue is still there with #define FORCE_WORD_WRITE 1:
jffs2: Write clean marker to block at 0x000a failed: -5
MTD do_write_oneword_once(): software timeout
Which kernel version has been tested about this?
Since the buffered writes dis
Hello Tokunori-san,
On 15.12.21 18:34, Tokunori Ikegami wrote:
> Hi Ahmad-san,
Thanks for your reply (and Thorsten for the reminder) and sorry for
the delay. I had a lot of backlog after my time off.
> Sorry for the regression issue by the change: dfeae1073583.
> To make sure could you please tr
Hi, this is your Linux kernel regression tracker speaking.
On 15.12.21 18:34, Tokunori Ikegami wrote:
> Hi Ahmad-san,
>
> Sorry for the regression issue by the change: dfeae1073583.
> To make sure could you please try with the word write instead of the
> buffered writes?
Ahmad, did you try what
Hi Ahmad-san,
Sorry for the regression issue by the change: dfeae1073583.
To make sure could you please try with the word write instead of the
buffered writes?
FYI: There are some changes to disable the buffered writes as below.
1.
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=tar
[TLDR: adding this regression to regzbot; most of this mail is compiled
from a few templates paragraphs some of you might have seen already.]
Hi, this is your Linux kernel regression tracker speaking.
Top-posting for once, to make this easy accessible to everyone.
Thanks for the report.
Adding
Hi,
I've been investigating a breakage on a PowerPC MPC8313: The SoC is connected
via the "Enhanced Local Bus Controller" to a 8-bit-parallel S29GL064N flash,
which is represented as a memory-mapped cfi-flash.
The regression began in v4.17-rc1 with
dfeae1073583 ("mtd: cfi_cmdset_0002: Change w
17 matches
Mail list logo
