RE: [PATCH RFC] ata: sata-rcar: Fix .dma_boundary for WRITE DMA EXT timeout issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Geert-san,

> From: Geert Uytterhoeven, Sent: Thursday, September 17, 2020 5:05 PM
> 
> Hi Shimoda-san,
> 
> On Thu, Sep 17, 2020 at 10:00 AM Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@xxxxxxxxxxx> wrote:
> > > From: Geert Uytterhoeven, Sent: Wednesday, September 16, 2020 8:48 PM
> > > 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.
> 
> Thanks for testing!
> 
> Can I add your Tested-by?

Yes. Thanks!

Best regards,
Yoshihiro Shimoda





[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux