Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0

Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0

[Jeff Moyer]

Mike Snitzer <snitzer@redhat.com> writes:

> On Mon, Aug 03 2015 at  4:12am -0400,
> Joerg Roedel <joro@8bytes.org> wrote:
>
>> On Sun, Aug 02, 2015 at 08:48:06PM +0200, Andreas Hartmann wrote:
>> > >>https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34b48db66e08ca1c1bc07cf305d672ac940268dc
>> > >>
>> > >>block: remove artifical max_hw_sectors cap
>> 
>> Looking at the patch, it seems to me that it just uncovered a bug
>> elsewhere. It looks like an underlying driver doesn't expect the
>> big io-requests that the patch enables and does not dma-map the whole
>> target buffer, causing the IO_PAGE_FAULTs later.
>
> That patch has caused issues elsewhere too, see this 'Revert "block:
> remove artifical max_hw_sectors cap"' thread (if/when lkml.org
> cooperates): https://lkml.org/lkml/2015/7/20/572
>
> But it could be that there is a need for a horkage fix for this specific
> hardware? something comparable to this?:
> http://git.kernel.org/linus/af34d637637eabaf49406eb35c948cd51ba262a6
>
> We are running out of time to fix these whack-a-mole issues in 4.2
> though.

CC-ing linux-ide.  Original dm-devel posting:
  https://www.redhat.com/archives/dm-devel/2015-July/msg00178.html

Andreas, I would be curious to know what the value of
/sys/block/sdX/queue/max_hw_sectors_kb is for the affected disks.

Cheers,
Jeff

Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0

[Andreas Hartmann]

On 08/04/2015 at 06:10 PM Jeff Moyer wrote:
> Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> 
>> On Mon, Aug 03 2015 at  4:12am -0400,
>> Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org> wrote:
>>
>>> On Sun, Aug 02, 2015 at 08:48:06PM +0200, Andreas Hartmann wrote:
>>>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34b48db66e08ca1c1bc07cf305d672ac940268dc
>>>>>>
>>>>>> block: remove artifical max_hw_sectors cap
>>>
>>> Looking at the patch, it seems to me that it just uncovered a bug
>>> elsewhere. It looks like an underlying driver doesn't expect the
>>> big io-requests that the patch enables and does not dma-map the whole
>>> target buffer, causing the IO_PAGE_FAULTs later.
>>
>> That patch has caused issues elsewhere too, see this 'Revert "block:
>> remove artifical max_hw_sectors cap"' thread (if/when lkml.org
>> cooperates): https://lkml.org/lkml/2015/7/20/572
>>
>> But it could be that there is a need for a horkage fix for this specific
>> hardware? something comparable to this?:
>> http://git.kernel.org/linus/af34d637637eabaf49406eb35c948cd51ba262a6
>>
>> We are running out of time to fix these whack-a-mole issues in 4.2
>> though.
> 
> CC-ing linux-ide.  Original dm-devel posting:
>   https://www.redhat.com/archives/dm-devel/2015-July/msg00178.html
> 
> Andreas, I would be curious to know what the value of
> /sys/block/sdX/queue/max_hw_sectors_kb is for the affected disks.


It's always 32767.

Where does this value come from? Is it empirical or is it calculated (on
base of which parameters)?


Devices are:

1 x Corsair Force GT (SSD)
2 x ST3000DM001-1CH166 (rotational) (WD)


How can I set a higher max_sectors_kb on boot before the partitions are
mounted (-> as kernel option)? Mounting the partitions here (w/ systemd)
is the easiest and best way to trigger the problem!



Thanks,
Andreas

Re: AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0

[Andreas Hartmann]

On 08/04/2015 at 08:11 PM, Andreas Hartmann wrote:
> On 08/04/2015 at 06:10 PM Jeff Moyer wrote:
>> Mike Snitzer <snitzer@redhat.com> writes:
>>
>>> On Mon, Aug 03 2015 at  4:12am -0400,
>>> Joerg Roedel <joro@8bytes.org> wrote:
>>>
>>>> On Sun, Aug 02, 2015 at 08:48:06PM +0200, Andreas Hartmann wrote:
>>>>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34b48db66e08ca1c1bc07cf305d672ac940268dc
>>>>>>>
>>>>>>> block: remove artifical max_hw_sectors cap
>>>>
>>>> Looking at the patch, it seems to me that it just uncovered a bug
>>>> elsewhere. It looks like an underlying driver doesn't expect the
>>>> big io-requests that the patch enables and does not dma-map the whole
>>>> target buffer, causing the IO_PAGE_FAULTs later.
>>>
>>> That patch has caused issues elsewhere too, see this 'Revert "block:
>>> remove artifical max_hw_sectors cap"' thread (if/when lkml.org
>>> cooperates): https://lkml.org/lkml/2015/7/20/572
>>>
>>> But it could be that there is a need for a horkage fix for this specific
>>> hardware? something comparable to this?:
>>> http://git.kernel.org/linus/af34d637637eabaf49406eb35c948cd51ba262a6
>>>
>>> We are running out of time to fix these whack-a-mole issues in 4.2
>>> though.
>>
>> CC-ing linux-ide.  Original dm-devel posting:
>>   https://www.redhat.com/archives/dm-devel/2015-July/msg00178.html
>>
>> Andreas, I would be curious to know what the value of
>> /sys/block/sdX/queue/max_hw_sectors_kb is for the affected disks.
> 
> 
> It's always 32767.
> 
> Where does this value come from? Is it empirical or is it calculated (on
> base of which parameters)?
> 
> 
> Devices are:
> 
> 1 x Corsair Force GT (SSD)
> 2 x ST3000DM001-1CH166 (rotational) (WD)
> 
> 
> How can I set a higher max_sectors_kb on boot before the partitions are
> mounted (-> as kernel option)? Mounting the partitions here (w/ systemd)
> is the easiest and best way to trigger the problem!

Please - no idea how to set higher max_sectors_kb before mounting of
partitions? Come on! I want to test exactly this situation!


Regards,
Andreas