* Re: [PATCH 1/7] ѕd: split sd_setup_discard_cmnd
From: hch @ 2017-03-30 8:49 UTC (permalink / raw)
To: axboe@kernel.dk
Cc: Bart Van Assche, hch@lst.de, tj@kernel.org,
martin.petersen@oracle.com, linux-scsi@vger.kernel.org,
linux-block@vger.kernel.org, linux-ide@vger.kernel.org
In-Reply-To: <20170328140509.GA27578@kernel.dk>
On Tue, Mar 28, 2017 at 08:05:09AM -0600, axboe@kernel.dk wrote:
> > Although I know this is an issue in the existing code and not something
> > introduced by you: please consider using logical_to_sectors() instead of
> > open-coding this function. Otherwise this patch looks fine to me.
>
> The downside of doing that is that we still call ilog2() twice, which
> sucks. Would be faster to cache ilog2(sector_size) and use that in the
> shift calculation.
I suspect that gcc is smart enough to optimize it away. That beeing said
while this looks like a nice cleanup this patch is just supposed to move
code, so I'd rather not add the change here and leave it for a separate
submission.
^ permalink raw reply
* 63786 linux-ide
From: beautyink @ 2017-03-29 22:22 UTC (permalink / raw)
To: linux-ide
[-- Attachment #1: 0845.zip --]
[-- Type: application/zip, Size: 2721 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/5] ATA/ARM: convert ARM/DaVinci to use libata PATA drivers
From: Tejun Heo @ 2017-03-29 15:35 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Russell King, Sergei Shtylyov, Arnd Bergmann,
Dmitry Eremin-Solenikov, Kevin Hilman, Sekhar Nori, linux-kernel,
linux-ide, linux-arm-kernel
In-Reply-To: <7423344.GzQhW9fIvG@amdc3058>
On Fri, Mar 24, 2017 at 04:38:24PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Thursday, March 23, 2017 07:27:05 PM Sekhar Nori wrote:
> > On Wednesday 22 March 2017 11:50 PM, Bartlomiej Zolnierkiewicz wrote:
> > > Hi,
> > >
> > > This patchset adds Palmchip BK3710 IDE controller driver to
> > > libata and switches ARM/DaVinci to use it (instead of the old
> > > IDE driver).
> > >
> > > Sekhar, please check that it still works after changes, thanks.
> >
> > Did some basic mount/read/write tests, it passed.
>
> Thanks for checking.
>
> I guess that you can merge the patchset now to your tree
> (with Tejun's ACK for the whole patches and Sergei's ACK
> for ATA changes).
Acked-by: Tejun Heo <tj@kernel.org>
Yeah, please feel free to route the series as you see fit.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] pata_atiixp: Fix IDE detection on SB7xx
From: Sergei Shtylyov @ 2017-03-29 10:34 UTC (permalink / raw)
To: Darren Stevens, tj; +Cc: tourula, linux-ide
In-Reply-To: <49ce56dc322.70129c23@auth.smtp.1and1.co.uk>
Hello!
On 3/28/2017 6:57 PM, Darren Stevens wrote:
> Commit: 5946fdaee4ba(pata_atiixp: Don't use unconnected secondary port on
Need space before the 1st paren, and summary enclosed in (""), not just ().
> SB600/SB700) disabled the check for secondary ports on AMD SB700/710/750
>
> While these chips have only 1 IDE port, it can be reconfigured on SB7xx
> to appear as a secondary channel, especially when 'Legacy IDE emulation'
> is enabled, breaking IDE detection on some boards with this chipset.
>
> Fix by removing the check for SB7xx.
>
> Fixes: 5946fdaee4ba(pata_atiixp: Don't use unconnected secondary port
> on SB600/SB700)
Required the same standardized format as described above.
> Signed-off-by: Darren Stevens <Darren@stevens-zone.net>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] pata_atiixp: Fix IDE detection on SB7xx
From: Tejun Heo @ 2017-03-28 17:00 UTC (permalink / raw)
To: Darren Stevens; +Cc: tourula, linux-ide
In-Reply-To: <49ce56dc322.70129c23@auth.smtp.1and1.co.uk>
Hello,
On Tue, Mar 28, 2017 at 04:57:16PM +0100, Darren Stevens wrote:
> Commit: 5946fdaee4ba(pata_atiixp: Don't use unconnected secondary port on
> SB600/SB700) disabled the check for secondary ports on AMD SB700/710/750
>
> While these chips have only 1 IDE port, it can be reconfigured on SB7xx
> to appear as a secondary channel, especially when 'Legacy IDE emulation'
> is enabled, breaking IDE detection on some boards with this chipset.
>
> Fix by removing the check for SB7xx.
>
> Fixes: 5946fdaee4ba(pata_atiixp: Don't use unconnected secondary port
> on SB600/SB700)
> Signed-off-by: Darren Stevens <Darren@stevens-zone.net>
Hmmm... I can replace the revert with this but can you please explain
why we want this in the commit message? Also, it'd be nice to cc
Markku and link to his report.
Thanks.
--
tejun
^ permalink raw reply
* Re: pata_atiixp regression in 4.11-rc1
From: Darren Stevens @ 2017-03-28 15:56 UTC (permalink / raw)
To: Tejun Heo; +Cc: Markku Pesonen, linux-ide
In-Reply-To: <20170328155846.GB28157@htj.duckdns.org>
Hello Tejun
On 28/03/2017, Tejun Heo wrote:
> One way or the other, there's a reported case of secondary port being
> used, so we can't mark it dummy no matter what the datasheet says. If
> whether the port is marked dummy or not matter much, we can try to do
> finer grained blacklisting or try to do something smarter.
The best option is just not to check the SB7xx series (patch to follow), as
AMD added this ability to these chips.
This is my bad, I thought the early SB700 docs I had were correct - sorry.
Regards
Darren
PS I've adjusted my mailer settings, hopefully this one will work.
^ permalink raw reply
* [PATCH] pata_atiixp: Fix IDE detection on SB7xx
From: Darren Stevens @ 2017-03-28 15:57 UTC (permalink / raw)
To: tj; +Cc: tourula, linux-ide
Commit: 5946fdaee4ba(pata_atiixp: Don't use unconnected secondary port on
SB600/SB700) disabled the check for secondary ports on AMD SB700/710/750
While these chips have only 1 IDE port, it can be reconfigured on SB7xx
to appear as a secondary channel, especially when 'Legacy IDE emulation'
is enabled, breaking IDE detection on some boards with this chipset.
Fix by removing the check for SB7xx.
Fixes: 5946fdaee4ba(pata_atiixp: Don't use unconnected secondary port
on SB600/SB700)
Signed-off-by: Darren Stevens <Darren@stevens-zone.net>
---
drivers/ata/pata_atiixp.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/ata/pata_atiixp.c b/drivers/ata/pata_atiixp.c
index 6c9aa95..843bb20 100644
--- a/drivers/ata/pata_atiixp.c
+++ b/drivers/ata/pata_atiixp.c
@@ -278,9 +278,8 @@ static int atiixp_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
};
const struct ata_port_info *ppi[] = { &info, &info };
- /* SB600/700 don't have secondary port wired */
- if ((pdev->device == PCI_DEVICE_ID_ATI_IXP600_IDE) ||
- (pdev->device == PCI_DEVICE_ID_ATI_IXP700_IDE))
+ /* SB600 doesn't have secondary port wired */
+ if (pdev->device == PCI_DEVICE_ID_ATI_IXP600_IDE)
ppi[1] = &ata_dummy_port_info;
return ata_pci_bmdma_init_one(pdev, ppi, &atiixp_sht, NULL,
--
1.7.10.4
^ permalink raw reply related
* Re: pata_atiixp regression in 4.11-rc1
From: Tejun Heo @ 2017-03-28 15:58 UTC (permalink / raw)
To: Markku Pesonen; +Cc: Darren Stevens, linux-ide
In-Reply-To: <d9c9cb23-e67f-779d-240d-e02f7d87e405@gmail.com>
On Tue, Mar 28, 2017 at 12:57:42PM +0300, Markku Pesonen wrote:
> On 28.03.2017 11:24, Darren Stevens wrote:
> > Hello Tejun
> >
> > On 27/03/2017, Tejun Heo wrote:
> > > From a431ecd2d459da3c91a612061f09eb422ffe78e2 Mon Sep 17 00:00:00 2001
> > > From: Tejun Heo <tj@kernel.org>
> > > Date: Mon, 27 Mar 2017 13:52:00 -0400
> > > Subject: [PATCH] Revert "pata_atiixp: Don't use unconnected secondary
> > > port on SB600/SB700"
> > >
> > > This reverts commit 5946fdaee4ba449e8fbb5d403e1ed69437f916e8.
> > >
> > > The original commit's assumption that the secondary port is
> > > unconnected turns out to be false.
> >
> > Not entirely. I based my patch on information in AMD's document
> > 43366_sb7xx_bdg_pub_1.00.p
>
> I found this in the AMD SB710 Databook, rev 1.60, p. 56:
> "The integrated parallel ATA controller contains a single channel but
> can be configured as primary or secondary channel."
>
> The IDE connector on my Asrock 980DE3/U3S3 motherboard is configured as
> the secondary channel. The primary channel is used by the optional
> SATA-IDE emulation mode.
>
> I don't know much about kernel programming, southbridges, or ata
> controllers, but I hope this bit of information helps.
One way or the other, there's a reported case of secondary port being
used, so we can't mark it dummy no matter what the datasheet says. If
whether the port is marked dummy or not matter much, we can try to do
finer grained blacklisting or try to do something smarter.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 1/7] ѕd: split sd_setup_discard_cmnd
From: axboe @ 2017-03-28 14:05 UTC (permalink / raw)
To: Bart Van Assche
Cc: hch@lst.de, tj@kernel.org, martin.petersen@oracle.com,
linux-scsi@vger.kernel.org, linux-block@vger.kernel.org,
linux-ide@vger.kernel.org
In-Reply-To: <1490653474.7897.13.camel@sandisk.com>
On Mon, Mar 27 2017, Bart Van Assche wrote:
> On Mon, 2017-03-20 at 16:43 -0400, Christoph Hellwig wrote:
> > + u64 sector = blk_rq_pos(rq) >> (ilog2(sdp->sector_size) - 9);
> > + u32 nr_sectors = blk_rq_sectors(rq) >> (ilog2(sdp->sector_size) - 9);
>
> Although I know this is an issue in the existing code and not something
> introduced by you: please consider using logical_to_sectors() instead of
> open-coding this function. Otherwise this patch looks fine to me.
The downside of doing that is that we still call ilog2() twice, which
sucks. Would be faster to cache ilog2(sector_size) and use that in the
shift calculation.
--
Jens Axboe
^ permalink raw reply
* Re: pata_atiixp regression in 4.11-rc1
From: Markku Pesonen @ 2017-03-28 9:57 UTC (permalink / raw)
To: Darren Stevens; +Cc: Tejun Heo, linux-ide
In-Reply-To: <49cdecb0846.6a8a0888@auth.smtp.1and1.co.uk>
On 28.03.2017 11:24, Darren Stevens wrote:
> Hello Tejun
>
> On 27/03/2017, Tejun Heo wrote:
>> From a431ecd2d459da3c91a612061f09eb422ffe78e2 Mon Sep 17 00:00:00 2001
>> From: Tejun Heo <tj@kernel.org>
>> Date: Mon, 27 Mar 2017 13:52:00 -0400
>> Subject: [PATCH] Revert "pata_atiixp: Don't use unconnected secondary
>> port on SB600/SB700"
>>
>> This reverts commit 5946fdaee4ba449e8fbb5d403e1ed69437f916e8.
>>
>> The original commit's assumption that the secondary port is
>> unconnected turns out to be false.
>
> Not entirely. I based my patch on information in AMD's document
> 43366_sb7xx_bdg_pub_1.00.p
I found this in the AMD SB710 Databook, rev 1.60, p. 56:
"The integrated parallel ATA controller contains a single channel but
can be configured as primary or secondary channel."
The IDE connector on my Asrock 980DE3/U3S3 motherboard is configured as
the secondary channel. The primary channel is used by the optional
SATA-IDE emulation mode.
I don't know much about kernel programming, southbridges, or ata
controllers, but I hope this bit of information helps.
^ permalink raw reply
* Delock 89384 Sata Controller Causes Lockups Under Heavy Load
From: Matthias Peter Walther @ 2017-03-28 9:33 UTC (permalink / raw)
To: linux-ide
Hello,
I'm new to this list and I signed up, because I found an instability
with the following sata controller:
Product name: Delock 89384 10 Port PCIe 2.0 x2 Low Profile retail
Identifies as: 03:00.0 SATA controller: ASMedia Technology Inc. Device
0625 (rev 01)
(PCIe to 10x sata controller card)
Problem description: The controller works and recognizes all my drives.
But under heavy load, e. g. a mdadm raid-6 resync or just a dd to a
file, it keeps causing lockups and random device link resettings on
multiple devices.
I spend the last two weeks on replacing components in this server, the
controller is definitely the problem. Everything works fine with a
Marvell 9215 controller and I tried the controller with three different
mainboards and kernel versions 3.2, 4.4 and 4.10. The controller or its
kernel driver definitely cause these lock ups. I made sure, that all
drives were properly connected. [Syslog attached at the bottom of this
mail.]
Syslog of one of these resets: If the level of stress is high enough,
they happen on all connected devices (seemingly random) from different
manufacturers (WesternDigital and Seagate) and different types of
models. So this is probably not a bug in the firmware of one of the drives.
Log:
Mar 24 09:01:43 Server1 kernel: [ 1807.338347] ata3.00: exception Emask
0x0 SAct 0x0 SErr 0x0 action
0x6 frozen
Mar 24 09:01:43 Server1 kernel: [ 1807.340701] ata3.00: failed command:
FLUSH CACHE EXT
Mar 24 09:01:43 Server1 kernel: [ 1807.343078] ata3.00: cmd
ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
Mar 24 09:01:43 Server1 kernel: [ 1807.343078] res
40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
Mar 24 09:01:43 Server1 kernel: [ 1807.349717] ata3.00: status: { DRDY }
Mar 24 09:01:43 Server1 kernel: [ 1807.353029] ata3: hard resetting link
Mar 24 09:01:43 Server1 kernel: [ 1807.665533] ata3: SATA link up 6.0
Gbps (SStatus 133 SControl 300)
Mar 24 09:01:43 Server1 kernel: [ 1807.667000] ata3.00: configured for
UDMA/133
Mar 24 09:01:43 Server1 kernel: [ 1807.667007] ata3.00: retrying FLUSH
0xea Emask 0x4
Mar 24 09:01:43 Server1 kernel: [ 1807.667164] ata3.00: device reported
invalid CHS sector 0
Mar 24 09:01:43 Server1 kernel: [ 1807.667183] ata3: EH complete
Whenever such a lock up happens, the whole partition is not read- or
writeable for at least 90 seconds and sometimes several minutes. But the
system never crashed. I tried to google the controller card, didn't find
much about it.
Any advice would be much appreciated .
Greetings,
Matthias
^ permalink raw reply
* Re: Delock 89384 Sata Controller Causes Lockups Under Heavy Load
From: Jack Wang @ 2017-03-28 8:51 UTC (permalink / raw)
To: m.wa, linux-ide
In-Reply-To: <b71c21b1-bb72-25cc-2528-bdee33eb4ca3@uni-muenster.de>
2017-03-28 2:53 GMT+02:00 Matthias Peter Walther <m_walt11@uni-muenster.de>:
> Hello,
>
> I'm new to this list and I signed up, because I found an instability
> with the following sata controller:
>
> Product name: Delock 89384 10 Port PCIe 2.0 x2 Low Profile retail
> Identifies as: 03:00.0 SATA controller: ASMedia Technology Inc. Device
> 0625 (rev 01)
> (PCIe to 10x sata controller card)
>
> Problem description: The controller works and recognizes all my drives.
> But under heavy load, e. g. a mdadm raid-6 resync or just a dd to a
> file, it keeps causing lockups and random device link resettings on
> multiple devices.
>
> I spend the last two weeks on replacing components in this server, the
> controller is definitely the problem. Everything works fine with a
> Marvell 9215 controller and I tried the controller with three different
> mainboards and kernel versions 3.2, 4.4 and 4.10. The controller or its
> kernel driver definitely cause these lock ups. I made sure, that all
> drives were properly connected. [Syslog attached at the bottom of this
> mail.]
>
> As I am an experienced linux user, but new to this, first questions:
>
> Is this the right place to seek for help?
>
> If not so: Where might I get help with this?
This should go to linux-ide instead of linux-scsi.
Maybe the maintainer could give you some help.
You can also take a look at
https://ata.wiki.kernel.org/index.php/Libata_error_messages
>
> If so: Does anybody have an idea, what might causes this problem.
>
> My abilities: I can test patches on the mainline kernel. I can't code,
> as I lack any kind of knowledge about the sata standard. I have the
> controller card and an empty spare device here, to run any kind of tests.
>
> Syslog of one of these resets: If the level of stress is high enough,
> they happen on all connected devices (seemingly random) from different
> manufacturers (WesternDigital and Seagate) and different types of
> models. So this is probably not a bug in the firmware of one of the drives.
>
> Log:
> Mar 24 09:01:43 Server1 kernel: [ 1807.338347] ata3.00: exception Emask
> 0x0 SAct 0x0 SErr 0x0 action
> 0x6 frozen
> Mar 24 09:01:43 Server1 kernel: [ 1807.340701] ata3.00: failed command:
> FLUSH CACHE EXT
> Mar 24 09:01:43 Server1 kernel: [ 1807.343078] ata3.00: cmd
> ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
> Mar 24 09:01:43 Server1 kernel: [ 1807.343078] res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask
> 0x4 (timeout)
> Mar 24 09:01:43 Server1 kernel: [ 1807.349717] ata3.00: status: { DRDY }
> Mar 24 09:01:43 Server1 kernel: [ 1807.353029] ata3: hard resetting link
> Mar 24 09:01:43 Server1 kernel: [ 1807.665533] ata3: SATA link up 6.0
> Gbps (SStatus 133 SControl 300)
> Mar 24 09:01:43 Server1 kernel: [ 1807.667000] ata3.00: configured for
> UDMA/133
> Mar 24 09:01:43 Server1 kernel: [ 1807.667007] ata3.00: retrying FLUSH
> 0xea Emask 0x4
> Mar 24 09:01:43 Server1 kernel: [ 1807.667164] ata3.00: device reported
> invalid CHS sector 0
> Mar 24 09:01:43 Server1 kernel: [ 1807.667183] ata3: EH complete
>
> Whenever such a lock up happens, the whole partition is not read or
> writeable for at least 90 seconds and sometimes several minutes. But the
> system never crashed. I tried to google the controller card, didn't find
> much about it.
>
> Any advice would be much appreciated :).
>
> Greetings,
> Matthias
>
>
Cheers,
Jack
^ permalink raw reply
* Re: pata_atiixp regression in 4.11-rc1
From: Darren Stevens @ 2017-03-28 8:24 UTC (permalink / raw)
To: Tejun Heo; +Cc: Markku Pesonen, linux-ide
In-Reply-To: <20170327175550.GB13353@htj.duckdns.org>
Hello Tejun
On 27/03/2017, Tejun Heo wrote:
> From a431ecd2d459da3c91a612061f09eb422ffe78e2 Mon Sep 17 00:00:00 2001
> From: Tejun Heo <tj@kernel.org>
> Date: Mon, 27 Mar 2017 13:52:00 -0400
> Subject: [PATCH] Revert "pata_atiixp: Don't use unconnected secondary
> port on SB600/SB700"
>
> This reverts commit 5946fdaee4ba449e8fbb5d403e1ed69437f916e8.
>
> The original commit's assumption that the secondary port is
> unconnected turns out to be false.
Not entirely. I based my patch on information in AMD's document
43366_sb7xx_bdg_pub_1.00.p
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Reported-by: Markku Pesonen <tourula@gmail.com>
> Fixes: 5946fdaee4ba ("pata_atiixp: Don't use unconnected secondary port
> on SB600/SB700") Cc: Darren Stevens <darren@stevens-zone.net>
> ---
> drivers/ata/pata_atiixp.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/ata/pata_atiixp.c b/drivers/ata/pata_atiixp.c
> index 6c9aa95..49d705c 100644
> --- a/drivers/ata/pata_atiixp.c
> +++ b/drivers/ata/pata_atiixp.c
> @@ -278,11 +278,6 @@ static int atiixp_init_one(struct pci_dev *pdev,
> const struct pci_device_id *id) };
> const struct ata_port_info *ppi[] = { &info, &info };
>
> - /* SB600/700 don't have secondary port wired */
> - if ((pdev->device == PCI_DEVICE_ID_ATI_IXP600_IDE) ||
> - (pdev->device == PCI_DEVICE_ID_ATI_IXP700_IDE))
> - ppi[1] = &ata_dummy_port_info;
> -
> return ata_pci_bmdma_init_one(pdev, ppi, &atiixp_sht, NULL,
> ATA_HOST_PARALLEL_SCAN);
> }
Regards
^ permalink raw reply
* Dear, I need your help to invest in your country,
From: aishagaddafi12 @ 2017-03-28 4:11 UTC (permalink / raw)
Mrs Aisha Al-Qaddafi is my name, the daughter of late Libyan
president, I have investment
funds the sum of $27.5 million USD, I am interested in you for
investment project assistance in your country,
i shall compensate you 30% of the total sum after the funds are
transfer into your account,
kindly reply for more information via my mailbox: mrs.aishaalqaddafi0
(at)gmail.com
Greetings from Mrs Aisha Al-qaddafi
Mrs Aisha Al-qaddafi
^ permalink raw reply
* Re: [PATCH 7/7] sd: use ZERO_PAGE for WRITE_SAME payloads
From: Bart Van Assche @ 2017-03-27 23:40 UTC (permalink / raw)
To: hch@lst.de, tj@kernel.org, martin.petersen@oracle.com,
axboe@kernel.dk
Cc: linux-scsi@vger.kernel.org, linux-block@vger.kernel.org,
linux-ide@vger.kernel.org
In-Reply-To: <20170320204319.12628-8-hch@lst.de>
On Mon, 2017-03-20 at 16:43 -0400, Christoph Hellwig wrote:
> We're never touching the contents of the page, so save a memory
> allocation for these cases.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/scsi/sd.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index c18fe9ff1f8f..af632e350ab4 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -756,7 +756,7 @@ static int sd_setup_write_same16_cmnd(struct scsi_cmnd *cmd)
> u32 nr_sectors = blk_rq_sectors(rq) >> (ilog2(sdp->sector_size) - 9);
> u32 data_len = sdp->sector_size;
>
> - rq->special_vec.bv_page = alloc_page(GFP_ATOMIC | __GFP_ZERO);
> + rq->special_vec.bv_page = ZERO_PAGE(0);
> if (!rq->special_vec.bv_page)
> return BLKPREP_DEFER;
> rq->special_vec.bv_offset = 0;
> @@ -785,7 +785,7 @@ static int sd_setup_write_same10_cmnd(struct scsi_cmnd *cmd, bool unmap)
> u32 nr_sectors = blk_rq_sectors(rq) >> (ilog2(sdp->sector_size) - 9);
> u32 data_len = sdp->sector_size;
>
> - rq->special_vec.bv_page = alloc_page(GFP_ATOMIC | __GFP_ZERO);
> + rq->special_vec.bv_page = ZERO_PAGE(0);
> if (!rq->special_vec.bv_page)
> return BLKPREP_DEFER;
> rq->special_vec.bv_offset = 0;
> @@ -1256,7 +1256,8 @@ static void sd_uninit_command(struct scsi_cmnd *SCpnt)
> {
> struct request *rq = SCpnt->request;
>
> - if (rq->rq_flags & RQF_SPECIAL_PAYLOAD)
> + if ((rq->rq_flags & RQF_SPECIAL_PAYLOAD) &&
> + rq->special_vec.bv_page != ZERO_PAGE(0))
> __free_page(rq->special_vec.bv_page);
>
> if (SCpnt->cmnd != scsi_req(rq)->cmd) {
Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com>
^ permalink raw reply
* Re: [PATCH 6/7] sd: support multi-range TRIM for ATA disks
From: Bart Van Assche @ 2017-03-27 23:38 UTC (permalink / raw)
To: hch@lst.de, tj@kernel.org, martin.petersen@oracle.com,
axboe@kernel.dk
Cc: linux-scsi@vger.kernel.org, linux-block@vger.kernel.org,
linux-ide@vger.kernel.org
In-Reply-To: <20170320204319.12628-7-hch@lst.de>
On Mon, 2017-03-20 at 16:43 -0400, Christoph Hellwig wrote:
> @@ -698,13 +698,19 @@ static void sd_config_discard(struct scsi_disk *sdkp, unsigned int mode)
> break;
>
> case SD_LBP_ATA_TRIM:
> - max_blocks = 65535 * (512 / sizeof(__le64));
> + max_ranges = 512 / sizeof(__le64);
> + max_range_size = USHRT_MAX;
> + max_blocks = max_ranges * max_range_size;
> if (sdkp->device->ata_trim_zeroes_data)
> q->limits.discard_zeroes_data = 1;
> break;
> }
>
> blk_queue_max_discard_sectors(q, max_blocks * (logical_block_size >> 9));
> + if (max_ranges)
> + blk_queue_max_discard_segments(q, max_ranges);
> + if (max_range_size)
> + blk_queue_max_discard_segment_size(q, max_range_size);
> queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, q);
> }
Hello Christoph,
Does blk_queue_max_discard_segment_size() expect a second argument that is a
number of bytes? Is max_range_size a number of logical blocks that each have
a size 1 << sector_shift?
> @@ -826,14 +832,21 @@ static int sd_setup_ata_trim_cmnd(struct scsi_cmnd *cmd)
> cmd->cmnd[8] = data_len;
>
> buf = page_address(rq->special_vec.bv_page);
> - for (i = 0; i < (data_len >> 3); i++) {
> - u64 n = min(nr_sectors, 0xffffu);
> + __rq_for_each_bio(bio, rq) {
> + u64 sector = bio->bi_iter.bi_sector >> (sector_shift - 9);
> + u32 nr_sectors = bio->bi_iter.bi_size >> sector_shift;
>
> - buf[i] = cpu_to_le64(sector | (n << 48));
> - if (nr_sectors <= 0xffff)
> - break;
> - sector += 0xffff;
> - nr_sectors -= 0xffff;
> + do {
> + u64 n = min(nr_sectors, 0xffffu);
> +
> + buf[i] = cpu_to_le64(sector | (n << 48));
> + if (nr_sectors <= 0xffff)
> + break;
> + sector += 0xffff;
> + nr_sectors -= 0xffff;
> + i++;
> +
> + } while (!WARN_ON_ONCE(i >= data_len >> 3));
> }
>
> cmd->allowed = SD_MAX_RETRIES;
It's unfortunate that the loop-end test occurs twice (i < data_len >> 3).
Please consider using put_unaligned_le64() instead of cpu_to_le64() such
that the data type of buf can be changed from __le64* into void *. With
that change and by introducing e.g. the following:
void *end;
[ ... ]
end = (void *)buf + data_len;
the loop variable 'i' can be eliminated. If buf[i++] = ... would be
changed into *buf++ = ... then that would allow to change the two
occurrences of (i < data_len >> 3) into (buf < end).
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH 5/7] block: add a max_discard_segment_size queue limit
From: Bart Van Assche @ 2017-03-27 23:09 UTC (permalink / raw)
To: hch@lst.de, tj@kernel.org, martin.petersen@oracle.com,
axboe@kernel.dk
Cc: linux-scsi@vger.kernel.org, linux-block@vger.kernel.org,
linux-ide@vger.kernel.org
In-Reply-To: <20170320204319.12628-6-hch@lst.de>
On Mon, 2017-03-20 at 16:43 -0400, Christoph Hellwig wrote:
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index 5a7da607ca04..3b3bd646f580 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -333,6 +333,7 @@ struct queue_limits {
> unsigned short max_segments;
> unsigned short max_integrity_segments;
> unsigned short max_discard_segments;
> + unsigned int max_discard_segment_size;
>
> unsigned char misaligned;
> unsigned char discard_misaligned;
> @@ -1150,6 +1151,8 @@ extern void blk_queue_max_segments(struct request_queue *, unsigned short);
> extern void blk_queue_max_discard_segments(struct request_queue *,
> unsigned short);
> extern void blk_queue_max_segment_size(struct request_queue *, unsigned int);
> +extern void blk_queue_max_discard_segment_size(struct request_queue *,
> + unsigned int);
> extern void blk_queue_max_discard_sectors(struct request_queue *q,
> unsigned int max_discard_sectors);
> extern void blk_queue_max_write_same_sectors(struct request_queue *q,
> @@ -1415,6 +1418,11 @@ static inline unsigned int queue_max_segment_size(struct request_queue *q)
> return q->limits.max_segment_size;
> }
>
> +static inline unsigned int queue_max_discard_segment_size(struct request_queue *q)
> +{
> + return q->limits.max_discard_segment_size;
> +}
> +
> static inline unsigned short queue_logical_block_size(struct request_queue *q)
> {
> int retval = 512;
Hello Christoph,
It's probably a good idea to add a comment somewhere that the unit of
max_discard_segment_size is one byte.
Additionally, should it be mentioned in the commit message that this
patch limits the maximum discard segment size to 4 GB?
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH 2/7] sd: provide a new ata trim provisioning mode
From: Bart Van Assche @ 2017-03-27 22:40 UTC (permalink / raw)
To: hch@lst.de, tj@kernel.org, martin.petersen@oracle.com,
axboe@kernel.dk
Cc: linux-scsi@vger.kernel.org, linux-block@vger.kernel.org,
linux-ide@vger.kernel.org
In-Reply-To: <20170320204319.12628-3-hch@lst.de>
On Mon, 2017-03-20 at 16:43 -0400, Christoph Hellwig wrote:
> + case SD_LBP_ATA_TRIM:
> + max_blocks = 65535 * (512 / sizeof(__le64));
> + if (sdkp->device->ata_trim_zeroes_data)
> + q->limits.discard_zeroes_data = 1;
> + break;
Do we need a comment here that explains where the numbers 65535 and
512 come from?
> + u64 sector = blk_rq_pos(rq) >> (ilog2(sdp->sector_size) - 9);
> + u32 nr_sectors = blk_rq_sectors(rq) >> (ilog2(sdp->sector_size) - 9);
Please consider using logical_to_sectors() instead of open-coding this
function.
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH 1/7] ѕd: split sd_setup_discard_cmnd
From: Bart Van Assche @ 2017-03-27 22:24 UTC (permalink / raw)
To: hch@lst.de, tj@kernel.org, martin.petersen@oracle.com,
axboe@kernel.dk
Cc: linux-scsi@vger.kernel.org, linux-block@vger.kernel.org,
linux-ide@vger.kernel.org
In-Reply-To: <20170320204319.12628-2-hch@lst.de>
On Mon, 2017-03-20 at 16:43 -0400, Christoph Hellwig wrote:
> + u64 sector = blk_rq_pos(rq) >> (ilog2(sdp->sector_size) - 9);
> + u32 nr_sectors = blk_rq_sectors(rq) >> (ilog2(sdp->sector_size) - 9);
Although I know this is an issue in the existing code and not something
introduced by you: please consider using logical_to_sectors() instead of
open-coding this function. Otherwise this patch looks fine to me.
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: ata: add DT bindings for ahci-dm816 SATA controller
From: Tejun Heo @ 2017-03-27 18:06 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Rob Herring, Mark Rutland, Neil Armstrong, Michael Turquette,
Kevin Hilman, Patrick Titiano, Tony Lindgren, Sergei Shtylyov,
linux-ide, devicetree, linux-kernel
In-Reply-To: <1489489491-14195-2-git-send-email-bgolaszewski@baylibre.com>
On Tue, Mar 14, 2017 at 12:04:50PM +0100, Bartosz Golaszewski wrote:
> Add DT bindings for the onboard SATA controller present on the DM816x
> SoCs.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Applied to libata/for-4.12.
Thanks.
--
tejun
^ permalink raw reply
* Re: ata: WARNING in ata_bmdma_qc_issue
From: Tejun Heo @ 2017-03-27 18:03 UTC (permalink / raw)
To: Dmitry Vyukov; +Cc: linux-ide, LKML, syzkaller
In-Reply-To: <CACT4Y+b+t9TPkVhZPdoeSGfe3rujUdv267HW8yPqoTbKtLUScA@mail.gmail.com>
On Fri, Mar 24, 2017 at 03:14:14PM +0100, Dmitry Vyukov wrote:
> Hello,
>
> The following program triggers WARNING in ata_bmdma_qc_issue:
> https://gist.githubusercontent.com/dvyukov/7497a05853e58598b74a2c48030c41f4/raw/38885f75eb05f72bb47fff9c9de657728f529927/gistfile1.txt
Fix is already queued in libata/for-4.11-fixes. Will be pushed out soon.
Thanks.
--
tejun
^ permalink raw reply
* Re: pata_atiixp regression in 4.11-rc1
From: Tejun Heo @ 2017-03-27 17:49 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: Markku Pesonen, linux-ide, Darren Stevens
In-Reply-To: <1562903.8NG6OqSh5o@amdc3058>
Hello,
On Mon, Mar 27, 2017 at 11:22:41AM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> added patch author to Cc:
>
> On Sunday, March 26, 2017 10:31:17 AM Markku Pesonen wrote:
> > Hello,
> >
> > While testing Linux 4.11-rc1, I noticed that the IDE port on my
> > Asrock 980DE3/U3S3 motherboard stopped working.
> >
> > Reverting commit 5946fdaee4ba449e8fbb5d403e1ed69437f916e8
> > (pata_atiixp: Don't use unconnected secondary port on SB600/SB700)
> > made things work again.
> >
> > Apparently the secondary port is used on this motherboard.
I'm gonna revert the commit for now.
Thanks.
--
tejun
^ permalink raw reply
* Re: pata_atiixp regression in 4.11-rc1
From: Tejun Heo @ 2017-03-27 17:55 UTC (permalink / raw)
To: Markku Pesonen; +Cc: linux-ide, Darren Stevens
In-Reply-To: <22571b6e-a8f3-05bc-d68b-a728f595af1d@gmail.com>
>From a431ecd2d459da3c91a612061f09eb422ffe78e2 Mon Sep 17 00:00:00 2001
From: Tejun Heo <tj@kernel.org>
Date: Mon, 27 Mar 2017 13:52:00 -0400
Subject: [PATCH] Revert "pata_atiixp: Don't use unconnected secondary port on
SB600/SB700"
This reverts commit 5946fdaee4ba449e8fbb5d403e1ed69437f916e8.
The original commit's assumption that the secondary port is
unconnected turns out to be false.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Markku Pesonen <tourula@gmail.com>
Fixes: 5946fdaee4ba ("pata_atiixp: Don't use unconnected secondary port on SB600/SB700")
Cc: Darren Stevens <darren@stevens-zone.net>
---
drivers/ata/pata_atiixp.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/ata/pata_atiixp.c b/drivers/ata/pata_atiixp.c
index 6c9aa95..49d705c 100644
--- a/drivers/ata/pata_atiixp.c
+++ b/drivers/ata/pata_atiixp.c
@@ -278,11 +278,6 @@ static int atiixp_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
};
const struct ata_port_info *ppi[] = { &info, &info };
- /* SB600/700 don't have secondary port wired */
- if ((pdev->device == PCI_DEVICE_ID_ATI_IXP600_IDE) ||
- (pdev->device == PCI_DEVICE_ID_ATI_IXP700_IDE))
- ppi[1] = &ata_dummy_port_info;
-
return ata_pci_bmdma_init_one(pdev, ppi, &atiixp_sht, NULL,
ATA_HOST_PARALLEL_SCAN);
}
--
2.9.3
^ permalink raw reply related
* Re: pata_atiixp regression in 4.11-rc1
From: Bartlomiej Zolnierkiewicz @ 2017-03-27 9:22 UTC (permalink / raw)
To: Markku Pesonen; +Cc: Tejun Heo, linux-ide, Darren Stevens
In-Reply-To: <22571b6e-a8f3-05bc-d68b-a728f595af1d@gmail.com>
added patch author to Cc:
On Sunday, March 26, 2017 10:31:17 AM Markku Pesonen wrote:
> Hello,
>
> While testing Linux 4.11-rc1, I noticed that the IDE port on my
> Asrock 980DE3/U3S3 motherboard stopped working.
>
> Reverting commit 5946fdaee4ba449e8fbb5d403e1ed69437f916e8
> (pata_atiixp: Don't use unconnected secondary port on SB600/SB700)
> made things work again.
>
> Apparently the secondary port is used on this motherboard.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* pata_atiixp regression in 4.11-rc1
From: Markku Pesonen @ 2017-03-26 7:31 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-ide
Hello,
While testing Linux 4.11-rc1, I noticed that the IDE port on my
Asrock 980DE3/U3S3 motherboard stopped working.
Reverting commit 5946fdaee4ba449e8fbb5d403e1ed69437f916e8
(pata_atiixp: Don't use unconnected secondary port on SB600/SB700)
made things work again.
Apparently the secondary port is used on this motherboard.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox