From: Michael Ellerman <mpe@ellerman.id.au>
To: Niklas Cassel <cassel@kernel.org>
Cc: martin.petersen@oracle.com, dlemoal@kernel.org, hch@lst.de,
john.g.garry@oracle.com, linux-ide@vger.kernel.org,
linux-scsi@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
regressions@lists.linux.dev, doru.iorgulescu1@gmail.com
Subject: Re: [PATCH] ata: pata_macio: Fix max_segment_size with PAGE_SIZE == 64K
Date: Fri, 07 Jun 2024 13:10:25 +1000 [thread overview]
Message-ID: <87ikylphwe.fsf@mail.lhotse> (raw)
In-Reply-To: <ZmG0TUiw0Nagwroj@ryzen.lan>
Niklas Cassel <cassel@kernel.org> writes:
> On Thu, Jun 06, 2024 at 09:14:45PM +1000, Michael Ellerman wrote:
>> The pata_macio driver advertises a max_segment_size of 0xff00, because
>> the hardware doesn't cope with requests >= 64K.
>>
>> However the SCSI core requires max_segment_size to be at least
>> PAGE_SIZE, which is a problem for pata_macio when the kernel is built
>> with 64K pages.
>>
>> In older kernels the SCSI core would just increase the segment size to
>> be equal to PAGE_SIZE, however since the commit tagged below it causes a
>> warning and the device fails to probe:
>>
>> WARNING: CPU: 0 PID: 26 at block/blk-settings.c:202 .blk_validate_limits+0x2f8/0x35c
>> CPU: 0 PID: 26 Comm: kworker/u4:1 Not tainted 6.10.0-rc1 #1
>> Hardware name: PowerMac7,2 PPC970 0x390202 PowerMac
>> ...
>> NIP .blk_validate_limits+0x2f8/0x35c
>> LR .blk_alloc_queue+0xc0/0x2f8
>> Call Trace:
>> .blk_alloc_queue+0xc0/0x2f8
>> .blk_mq_alloc_queue+0x60/0xf8
>> .scsi_alloc_sdev+0x208/0x3c0
>> .scsi_probe_and_add_lun+0x314/0x52c
>> .__scsi_add_device+0x170/0x1a4
>> .ata_scsi_scan_host+0x2bc/0x3e4
>> .async_port_probe+0x6c/0xa0
>> .async_run_entry_fn+0x60/0x1bc
>> .process_one_work+0x228/0x510
>> .worker_thread+0x360/0x530
>> .kthread+0x134/0x13c
>> .start_kernel_thread+0x10/0x14
>> ...
>> scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured
>>
>> Although the hardware can't cope with a 64K segment, the driver
>> already deals with that internally by splitting large requests in
>> pata_macio_qc_prep(). That is how the driver has managed to function
>> until now on 64K kernels.
>>
>> So fix the driver to advertise a max_segment_size of 64K, which avoids
>> the warning and keeps the SCSI core happy.
>>
>> Fixes: afd53a3d8528 ("scsi: core: Initialize scsi midlayer limits before allocating the queue")
>> Reported-by: Guenter Roeck <linux@roeck-us.net>
>> Closes: https://lore.kernel.org/all/ce2bf6af-4382-4fe1-b392-cc6829f5ceb2@roeck-us.net/
>> Reported-by: Doru Iorgulescu <doru.iorgulescu1@gmail.com>
>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218858
>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>> ---
>
> Applied to libata/for-6.10-fixes:
> https://git.kernel.org/pub/scm/linux/kernel/git/libata/linux.git/log/?h=for-6.10-fixes
>
> With John's Reviewed-by from the other thread:
> https://lore.kernel.org/linux-ide/171362345502.571343.9746199181827642774.b4-ty@oracle.com/T/#t
Thanks.
cheers
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Niklas Cassel <cassel@kernel.org>
Cc: doru.iorgulescu1@gmail.com, martin.petersen@oracle.com,
linux-scsi@vger.kernel.org, john.g.garry@oracle.com,
linux-ide@vger.kernel.org, dlemoal@kernel.org,
linuxppc-dev@lists.ozlabs.org, hch@lst.de,
regressions@lists.linux.dev
Subject: Re: [PATCH] ata: pata_macio: Fix max_segment_size with PAGE_SIZE == 64K
Date: Fri, 07 Jun 2024 13:10:25 +1000 [thread overview]
Message-ID: <87ikylphwe.fsf@mail.lhotse> (raw)
In-Reply-To: <ZmG0TUiw0Nagwroj@ryzen.lan>
Niklas Cassel <cassel@kernel.org> writes:
> On Thu, Jun 06, 2024 at 09:14:45PM +1000, Michael Ellerman wrote:
>> The pata_macio driver advertises a max_segment_size of 0xff00, because
>> the hardware doesn't cope with requests >= 64K.
>>
>> However the SCSI core requires max_segment_size to be at least
>> PAGE_SIZE, which is a problem for pata_macio when the kernel is built
>> with 64K pages.
>>
>> In older kernels the SCSI core would just increase the segment size to
>> be equal to PAGE_SIZE, however since the commit tagged below it causes a
>> warning and the device fails to probe:
>>
>> WARNING: CPU: 0 PID: 26 at block/blk-settings.c:202 .blk_validate_limits+0x2f8/0x35c
>> CPU: 0 PID: 26 Comm: kworker/u4:1 Not tainted 6.10.0-rc1 #1
>> Hardware name: PowerMac7,2 PPC970 0x390202 PowerMac
>> ...
>> NIP .blk_validate_limits+0x2f8/0x35c
>> LR .blk_alloc_queue+0xc0/0x2f8
>> Call Trace:
>> .blk_alloc_queue+0xc0/0x2f8
>> .blk_mq_alloc_queue+0x60/0xf8
>> .scsi_alloc_sdev+0x208/0x3c0
>> .scsi_probe_and_add_lun+0x314/0x52c
>> .__scsi_add_device+0x170/0x1a4
>> .ata_scsi_scan_host+0x2bc/0x3e4
>> .async_port_probe+0x6c/0xa0
>> .async_run_entry_fn+0x60/0x1bc
>> .process_one_work+0x228/0x510
>> .worker_thread+0x360/0x530
>> .kthread+0x134/0x13c
>> .start_kernel_thread+0x10/0x14
>> ...
>> scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured
>>
>> Although the hardware can't cope with a 64K segment, the driver
>> already deals with that internally by splitting large requests in
>> pata_macio_qc_prep(). That is how the driver has managed to function
>> until now on 64K kernels.
>>
>> So fix the driver to advertise a max_segment_size of 64K, which avoids
>> the warning and keeps the SCSI core happy.
>>
>> Fixes: afd53a3d8528 ("scsi: core: Initialize scsi midlayer limits before allocating the queue")
>> Reported-by: Guenter Roeck <linux@roeck-us.net>
>> Closes: https://lore.kernel.org/all/ce2bf6af-4382-4fe1-b392-cc6829f5ceb2@roeck-us.net/
>> Reported-by: Doru Iorgulescu <doru.iorgulescu1@gmail.com>
>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218858
>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>> ---
>
> Applied to libata/for-6.10-fixes:
> https://git.kernel.org/pub/scm/linux/kernel/git/libata/linux.git/log/?h=for-6.10-fixes
>
> With John's Reviewed-by from the other thread:
> https://lore.kernel.org/linux-ide/171362345502.571343.9746199181827642774.b4-ty@oracle.com/T/#t
Thanks.
cheers
next prev parent reply other threads:[~2024-06-07 3:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-06 11:14 [PATCH] ata: pata_macio: Fix max_segment_size with PAGE_SIZE == 64K Michael Ellerman
2024-06-06 11:14 ` Michael Ellerman
2024-06-06 12:16 ` Damien Le Moal
2024-06-06 12:16 ` Damien Le Moal
2024-06-06 13:06 ` Niklas Cassel
2024-06-06 13:06 ` Niklas Cassel
2024-06-07 3:10 ` Michael Ellerman [this message]
2024-06-07 3:10 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ikylphwe.fsf@mail.lhotse \
--to=mpe@ellerman.id.au \
--cc=cassel@kernel.org \
--cc=dlemoal@kernel.org \
--cc=doru.iorgulescu1@gmail.com \
--cc=hch@lst.de \
--cc=john.g.garry@oracle.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=martin.petersen@oracle.com \
--cc=regressions@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.