Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Wednesday, September 16, 2020 8:48 PM
>
> Hi Shimoda-san,
>
> On Wed, Sep 16, 2020 at 1:27 PM Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@xxxxxxxxxxx> wrote:
> > When we wrote data to an SATA HDD, the following timeout issue
> > happened after the commit 429120f3df2d ("block: fix splitting
> > segments on boundary masks") was applied:
> >
> > # dd if=/dev/urandom of=/mnt/de1/file1-1024M bs=1M count=1024
> > ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> > ata1.00: failed command: WRITE DMA EXT
> > ata1.00: cmd 35/00:00:00:e6:0c/00:0a:00:00:00/e0 tag 0 dma 1310720 out
> > res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> > ata1.00: status: { DRDY }
> >
> > Since the commit changed get_max_segment_size()'s behavior,
> > unexpected behavior happens if .dma_boundary of this sata-rcar driver
> > is 0x1ffffffe in somewhere (my guess).
> >
> > By the way, the commit 8bfbeed58665 ("sata_rcar: correct
> > 'sata_rcar_sht'") changed the .dma_boundary as 0x1ffffffe, but this
> > number is related to ATAPI_DMA_TRANS_CNT register. So, we should set
> > the .dma_boundary as ATA_DMA_BOUNDARY (0xffff), and set
> > .max_segment_size to min(0x1ffffffe, dma_max_mapping_size()).
> >
> > After applied this, the timeout issue disappeared.
> >
> > Fixes: 8bfbeed58665 ("sata_rcar: correct 'sata_rcar_sht'")
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@xxxxxxxxxxx>
>
> Thanks for your patch!
>
> > ---
> > As I wrote the commit description, I couldn't find why the issue
> > was related to the .dma_boundary. So, I marked RFC on this patch.
> > I would appreciate it if you would give me some advice.
>
> There's also "[PATCH v2] ata: sata_rcar: Fix DMA boundary mask"
> (https://lore.kernel.org/linux-ide/20200811081712.4981-1-geert+renesas@xxxxxxxxx/)
>
> Is this related?
> Does my patch fix your issue, too?
Thank you for the information!
Your patch fixed my issue too. So, I think my patch should be dropped.
Best regards,
Yoshihiro Shimoda
