* [patch] lewisburg map/pcs register handling
From: Peter Chang @ 2017-11-14 23:55 UTC (permalink / raw)
To: linux-ide
[-- Attachment #1: Type: text/plain, Size: 162 bytes --]
mostly, intel made the registers wider so that the offsets aren't
right. it only matters if you don't populate all the ports and aren't
using the first port.
\p
[-- Attachment #2: 0001-ahci-lewisburg-MAP-PCS-register-handling.patch --]
[-- Type: text/x-patch, Size: 5169 bytes --]
From 62ccc6118960204769809a1ea9d162cf2c1c95e1 Mon Sep 17 00:00:00 2001
From: peter chang <dpf@google.com>
Date: Tue, 14 Nov 2017 13:43:15 -0800
Subject: [PATCH] ahci: lewisburg MAP / PCS register handling
registers are now 32-bits and the existing offsets mean that the
wrong registers are being updated.
Change-Id: I992b31bc9e789f9dfbeb29afeb0b7777e325ea71
---
drivers/ata/ahci.c | 34 +++++++++++++++++++++++++++-------
drivers/ata/ahci.h | 4 ++++
drivers/ata/libahci.c | 19 +++++++++++++++++++
3 files changed, 50 insertions(+), 7 deletions(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 9f78bb03bb76..16b0fac9f0ae 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -71,6 +71,7 @@ enum board_ids {
/* board IDs for specific chipsets in alphabetical order */
board_ahci_avn,
+ board_ahci_lbg,
board_ahci_mcp65,
board_ahci_mcp77,
board_ahci_mcp89,
@@ -174,6 +175,14 @@ static const struct ata_port_info ahci_port_info[] = {
.udma_mask = ATA_UDMA6,
.port_ops = &ahci_avn_ops,
},
+ [board_ahci_lbg] = {
+ AHCI_HFLAGS (AHCI_HFLAG_32BIT_MAP_PCS |
+ AHCI_HFLAG_PCI_PORT_MAP),
+ .flags = AHCI_FLAG_COMMON,
+ .pio_mask = ATA_PIO4,
+ .udma_mask = ATA_UDMA6,
+ .port_ops = &ahci_ops,
+ },
[board_ahci_mcp65] = {
AHCI_HFLAGS (AHCI_HFLAG_NO_FPDMA_AA | AHCI_HFLAG_NO_PMP |
AHCI_HFLAG_YES_NCQ),
@@ -374,14 +383,14 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0xa107), board_ahci }, /* Sunrise Point-H RAID */
{ PCI_VDEVICE(INTEL, 0xa10f), board_ahci }, /* Sunrise Point-H RAID */
{ PCI_VDEVICE(INTEL, 0x2822), board_ahci }, /* Lewisburg RAID*/
- { PCI_VDEVICE(INTEL, 0x2823), board_ahci }, /* Lewisburg AHCI*/
+ { PCI_VDEVICE(INTEL, 0x2823), board_ahci_lbg }, /* Lewisburg AHCI*/
{ PCI_VDEVICE(INTEL, 0x2826), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0x2827), board_ahci }, /* Lewisburg RAID*/
- { PCI_VDEVICE(INTEL, 0xa182), board_ahci }, /* Lewisburg AHCI*/
+ { PCI_VDEVICE(INTEL, 0xa182), board_ahci_lbg }, /* Lewisburg AHCI*/
{ PCI_VDEVICE(INTEL, 0xa186), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa1d2), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa1d6), board_ahci }, /* Lewisburg RAID*/
- { PCI_VDEVICE(INTEL, 0xa202), board_ahci }, /* Lewisburg AHCI*/
+ { PCI_VDEVICE(INTEL, 0xa202), board_ahci_lbg }, /* Lewisburg AHCI*/
{ PCI_VDEVICE(INTEL, 0xa206), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa252), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa256), board_ahci }, /* Lewisburg RAID*/
@@ -630,12 +639,23 @@ static int ahci_pci_reset_controller(struct ata_host *host)
if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
struct ahci_host_priv *hpriv = host->private_data;
u16 tmp16;
+ u32 tmp32;
/* configure PCS */
- pci_read_config_word(pdev, 0x92, &tmp16);
- if ((tmp16 & hpriv->port_map) != hpriv->port_map) {
- tmp16 |= hpriv->port_map;
- pci_write_config_word(pdev, 0x92, tmp16);
+ if (hpriv->flags & AHCI_HFLAG_32BIT_MAP_PCS)
+ pci_read_config_dword(pdev, 0x94, &tmp32);
+ else {
+ pci_read_config_word(pdev, 0x92, &tmp16);
+ tmp32 = tmp16;
+ }
+ if ((tmp32 & hpriv->port_map) != hpriv->port_map) {
+ tmp32 |= hpriv->port_map;
+ if (hpriv->flags & AHCI_HFLAG_32BIT_MAP_PCS)
+ pci_write_config_dword(pdev, 0x94, tmp32);
+ else {
+ tmp16 = tmp32;
+ pci_write_config_word(pdev, 0x92, tmp16);
+ }
}
}
diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index 8b61123d2c3c..a649107027de 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -251,6 +251,10 @@ enum {
AHCI_HFLAG_YES_ALPM = (1 << 23), /* force ALPM cap on */
AHCI_HFLAG_NO_WRITE_TO_RO = (1 << 24), /* don't write to read
only registers */
+ AHCI_HFLAG_32BIT_MAP_PCS = (1 << 25), /* MAP/PCS register
+ 32-bits wide */
+ AHCI_HFLAG_PCI_PORT_MAP = (1 << 26), /* port map in pci
+ config space */
/* ap->flags bits */
diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
index 3e286d86ab42..e65481d8e362 100644
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -40,6 +40,7 @@
#include <linux/interrupt.h>
#include <linux/dma-mapping.h>
#include <linux/device.h>
+#include <linux/pci.h>
#include <scsi/scsi_host.h>
#include <scsi/scsi_cmnd.h>
#include <linux/libata.h>
@@ -523,6 +524,24 @@ void ahci_save_initial_config(struct device *dev, struct ahci_host_priv *hpriv)
port_map &= hpriv->mask_port_map;
}
+ if (hpriv->flags & AHCI_HFLAG_PCI_PORT_MAP) {
+ struct pci_dev *pdev = to_pci_dev(dev);
+ u16 disabled;
+
+ if (hpriv->flags & AHCI_HFLAG_32BIT_MAP_PCS) {
+ u32 tmp;
+
+ pci_read_config_dword(pdev, 0x90, &tmp);
+ disabled = (tmp >> 16) & 0xffff;
+ } else {
+ pci_read_config_word(pdev, 0x90, &disabled);
+ disabled = (disabled >> 8) & 0xff;
+ }
+
+ dev_info(dev, "port_map:%x disabled:%x\n", port_map, disabled);
+ port_map &= ~disabled;
+ }
+
/* cross check port_map and cap.n_ports */
if (port_map) {
int map_ports = 0;
--
2.15.0.448.gf294e3d99a-goog
^ permalink raw reply related
* [PATCH] libata: sata_down_spd_limit should return if driver has not recorded sstatus speed
From: David Milburn @ 2017-11-14 22:17 UTC (permalink / raw)
To: linux-ide; +Cc: tj
During hotplug, it is possible for 6Gbps link speed to
be limited all the way down to 1.5 Gbps which may lead
to a slower link speed when drive is re-connected.
This behavior has been seen on a Intel Lewisburg SATA
controller (8086:a1d2) with HGST HUH728080ALE600 drive
where SATA link speed was limited to 1.5 Gbps and
when re-connected the link came up 3.0 Gbps.
This patch was retested on above configuration and
showed the hotplugged link to come back online at max
speed (6Gbps). I did not see the downgrade when testing
on Intel C600/X79, but retested patched linux-4.14-rc5
kernel and didn't see any side effects from this
change. Also, successfully retested hotplug on port
multiplier 3Gbps link.
Signed-off-by: David Milburn <dmilburn@redhat.com>
---
drivers/ata/libata-core.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index ee4c1ec..b72b242 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3081,12 +3081,17 @@ int sata_down_spd_limit(struct ata_link *link, u32 spd_limit)
mask &= ~(1 << bit);
/* Mask off all speeds higher than or equal to the current
- * one. Force 1.5Gbps if current SPD is not available.
+ * one. At this point if current SPD is not available and we
+ * previously recorded the link speed from the Status register,
+ * the driver has already masked off the highest bit so mask
+ * should already be set to 1 or 0. Otherwise, we should
+ * not force 1.5Gbps on a link where we have not previously
+ * recorded speed from Status register, just return in this case.
*/
if (spd > 1)
mask &= (1 << (spd - 1)) - 1;
else
- mask &= 1;
+ return -EINVAL;
/* were we already at the bottom? */
if (!mask)
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2] ahci: imx: Handle increased read failures for IMX53 temperature sensor in low frequency mode.
From: Tejun Heo @ 2017-11-13 20:18 UTC (permalink / raw)
To: Martyn Welch; +Cc: linux-ide, linux-kernel, Egor Starkov
In-Reply-To: <1510569061-28993-1-git-send-email-martyn.welch@collabora.co.uk>
On Mon, Nov 13, 2017 at 10:31:01AM +0000, Martyn Welch wrote:
> From: Egor Starkov <egor.starkov@ge.com>
>
> Extended testing has shown that the imx ahci driver sometimes requires
> more than the 100 attempts currently alotted in the driver to perform a
> successful temperature reading when running at minimum (throttled) CPU
> frequency.
>
> Debugging suggests that the read cycle can take 160 attempts (which given
> that the driver averages 80 readings from the ADC equates to one failure
> on each read).
>
> Increase the attempt limit to 200 in order to greatly reduce the
> likelihood of the driver failing to perform a temperature reading,
> especially at low CPU frequency.
>
> Signed-off-by: Egor Starkov <egor.starkov@ge.com>
> Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk>
Applied to libata/for-4.15.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH v1] ata: sata_dwc_460ex: Propagate platform device ID to DMA driver
From: Tejun Heo @ 2017-11-13 20:17 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: linux-ide
In-Reply-To: <20171110175937.83792-1-andriy.shevchenko@linux.intel.com>
On Fri, Nov 10, 2017 at 07:59:37PM +0200, Andy Shevchenko wrote:
> Propagate platform device ID to DMA driver to distinguish relationship
> between DMA and SATA instances.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applied to libata/for-4.15.
Thanks.
--
tejun
^ permalink raw reply
* Re: Manual unbind of ATA devices causes use-after-free
From: Tejun Heo @ 2017-11-13 20:10 UTC (permalink / raw)
To: Taras Kondratiuk; +Cc: linux-ide, linux-kernel, xe-linux-external, Lin Ming
In-Reply-To: <151060376750.7561.9196983678072496472@takondra-t460s>
Hello,
On Mon, Nov 13, 2017 at 12:09:27PM -0800, Taras Kondratiuk wrote:
> > cc'ing Lin. Lin, can you take a look at this?
>
> I'm ready to test whenever you have something. If you don't have time to
> look at this then can you recommend a proper way to fix it. Is it better
> to change device hierarchy back to previous state (revert 9a6d6a2ddabb)
> or add reference counting to ata_host?
We'll have to add refcnting to ata_host.
Thanks.
--
tejun
^ permalink raw reply
* Re: Manual unbind of ATA devices causes use-after-free
From: Taras Kondratiuk @ 2017-11-13 20:09 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-ide, linux-kernel, xe-linux-external, Lin Ming
In-Reply-To: <20171106152452.GA3252168@devbig577.frc2.facebook.com>
Hi Lin,
Quoting Tejun Heo (2017-11-06 07:24:52)
> Hello,
>
> On Fri, Nov 03, 2017 at 09:32:16AM -0700, Taras Kondratiuk wrote:
> > Also even if sg_release() is called before ata_host_release() there is
> > still no guarantee that the last reference will be dropped, because
> > sg_release() schedules sg_remove_sfp_usercontext() to do actual release
> > and the work may not be completed in time.
>
> Hmmm, we didn't use to put in ata device structs in the kobject tree,
> so this wasn't an issue. This was changed by 9a6d6a2ddabb ("ata: make
> ata port as parent device of scsi host") while adding the transport
> support. While doing that, we didn't change the release path to match
> it, so the failure.
>
> cc'ing Lin. Lin, can you take a look at this?
I'm ready to test whenever you have something. If you don't have time to
look at this then can you recommend a proper way to fix it. Is it better
to change device hierarchy back to previous state (revert 9a6d6a2ddabb)
or add reference counting to ata_host?
^ permalink raw reply
* (unknown),
From: Friedrich Mayrhofer @ 2017-11-12 15:09 UTC (permalink / raw)
This is the second time i am sending you this Email.
I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me
personally for more details.
Regards.
Friedrich Mayrhofer
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* Re:
From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw)
Attn:
I am wondering why You haven't respond to my email for some days now.
reference to my client's contract balance payment of (11.7M,USD)
Kindly get back to me for more details.
Best Regards
Amos Kalonzo
^ permalink raw reply
* Hello Dear...
From: M,Shakour Rosarita @ 2017-11-13 12:08 UTC (permalink / raw)
Hello Dear...
I know that this message will come to you as a surprise. I hoped that
you will not expose or betray this trust and confident that I am about
to repose on you, my name is M, Shakour Rosarita. I am 19 years old
Girl, female, from Tartu Syria, (never married) 61 kg, white in
complexion, and I am currently living in the refugee camp here in
Abidjan Ivory Coast, My late beloved father M,Shakour Hassin was a
renowned businessman and owner of Natour Petrol Station in Syria, he
was killed in a stampede riot in Tartu, Syria.
When I got the news about my parents. I fled to a nearby country
Jordan before I joined a ferry to Africa and came to Abidjan capital
city Ivory Coast West Africa find safety here.
I came in 2015 to Abidjan and I now live in refugee camps here as
refugees are allowed freely to enter here without, My late father
deposited (US$6.200.000.00m) My late father kept the money at the bank
of Africa, I want you to help me transfer the money to your hand so
that you will help me bring me into your country for my continue
education.
I sent my pictures here for you to see. Who I am seriously looking for
a good-person in my life, so I want to hear from you soon and learn
more about you.
I am an open-minded and friendly girl to share a good time with you
and have fun and enjoy on the go, bird watching, the rest of our
lives. My Hobbies, tourism books, dance, music, soccer, tennis,
swimming and cinema.
I would just think about you, including your dose and doesn’t .I
believe we will do well together, and live like one family.
Thank you and God bless you, for you in your promise to help me here,
looking forward to your reply by the grace of God and have a good day.
I hope you send me your photos as well? I await your next reply in
faith please reply through my private email at
(mshakourrosarita22@gmail.com):
Thanks.
Ms Rosarita
^ permalink raw reply
* [PATCH v2] ahci: imx: Handle increased read failures for IMX53 temperature sensor in low frequency mode.
From: Martyn Welch @ 2017-11-13 10:31 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-ide, linux-kernel, Egor Starkov, Martyn Welch
From: Egor Starkov <egor.starkov@ge.com>
Extended testing has shown that the imx ahci driver sometimes requires
more than the 100 attempts currently alotted in the driver to perform a
successful temperature reading when running at minimum (throttled) CPU
frequency.
Debugging suggests that the read cycle can take 160 attempts (which given
that the driver averages 80 readings from the ADC equates to one failure
on each read).
Increase the attempt limit to 200 in order to greatly reduce the
likelihood of the driver failing to perform a temperature reading,
especially at low CPU frequency.
Signed-off-by: Egor Starkov <egor.starkov@ge.com>
Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk>
---
v2: - Correct spelling issues in cover letter.
drivers/ata/ahci_imx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ata/ahci_imx.c b/drivers/ata/ahci_imx.c
index 787567e..a58bcc0 100644
--- a/drivers/ata/ahci_imx.c
+++ b/drivers/ata/ahci_imx.c
@@ -230,7 +230,7 @@ static int read_adc_sum(void *dev, u16 rtune_ctl_reg, void __iomem * mmio)
{
u16 adc_out_reg, read_sum;
u32 index, read_attempt;
- const u32 attempt_limit = 100;
+ const u32 attempt_limit = 200;
imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_RTUNE_CTL, mmio);
imx_phy_reg_write(rtune_ctl_reg, mmio);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] ahci: imx: Handle increased read failures for IMX53 temperature sensor in low frequency mode.
From: Sergei Shtylyov @ 2017-11-11 10:08 UTC (permalink / raw)
To: Martyn Welch, Tejun Heo; +Cc: linux-ide, Egor Starkov
In-Reply-To: <1510347098-20472-1-git-send-email-martyn.welch@collabora.co.uk>
Hello!
On 11/10/2017 11:51 PM, Martyn Welch wrote:
> From: Egor Starkov <egor.starkov@ge.com>
>
> Extended testing has shown that the imx ahci driver sometimes requires
> more than the 100 attempts currently alotted in the driver to perform a
> successful temperature reading when running at minimum (throttled) CPU
> frequency.
>
> Debugging suggests that the read cycle canitake 160 attempts (which given
Can take?
> that the driver averages 80 readings from the ADC equates to one failure
> on each read).
>
> Increase the attempt limit to 200 in order to greatly reduce the
> likelyhood of the driver failing to perform a temperature reading,
Likelihood.
> especially at low CPU frequency.
>
> Signed-off-by: Egor Starkov <egor.starkov@ge.com>
> Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk>
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH] ahci: imx: Handle increased read failures for IMX53 temperature sensor in low frequency mode.
From: Martyn Welch @ 2017-11-10 20:51 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-ide, Egor Starkov, Martyn Welch
From: Egor Starkov <egor.starkov@ge.com>
Extended testing has shown that the imx ahci driver sometimes requires
more than the 100 attempts currently alotted in the driver to perform a
successful temperature reading when running at minimum (throttled) CPU
frequency.
Debugging suggests that the read cycle canitake 160 attempts (which given
that the driver averages 80 readings from the ADC equates to one failure
on each read).
Increase the attempt limit to 200 in order to greatly reduce the
likelyhood of the driver failing to perform a temperature reading,
especially at low CPU frequency.
Signed-off-by: Egor Starkov <egor.starkov@ge.com>
Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk>
---
drivers/ata/ahci_imx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ata/ahci_imx.c b/drivers/ata/ahci_imx.c
index 787567e..a58bcc0 100644
--- a/drivers/ata/ahci_imx.c
+++ b/drivers/ata/ahci_imx.c
@@ -230,7 +230,7 @@ static int read_adc_sum(void *dev, u16 rtune_ctl_reg, void __iomem * mmio)
{
u16 adc_out_reg, read_sum;
u32 index, read_attempt;
- const u32 attempt_limit = 100;
+ const u32 attempt_limit = 200;
imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_RTUNE_CTL, mmio);
imx_phy_reg_write(rtune_ctl_reg, mmio);
--
1.8.3.1
^ permalink raw reply related
* Re: When will Linux support new RAID controllers
From: David F. @ 2017-11-10 19:06 UTC (permalink / raw)
To: Dennis Mungai
Cc: Christoph Hellwig, linux-raid@vger.kernel.org, linux-ide,
Dan Williams, linux-nvme
In-Reply-To: <CAKKYfmEqw48mjBsKoy=qeny6B1X8PKytSN4UwpvSupo87746kg@mail.gmail.com>
A patch would be great. There has been several cases where no option
to use AHCI mode available, or where a box seller would offer Linux as
an alternate boot option against Windows in RAID mode (on the mobo)
but could no longer provide Linux with their systems (without
additional costs for add-in raid controller).
On Fri, Nov 10, 2017 at 5:31 AM, Dennis Mungai <dmngaie@gmail.com> wrote:
> That feature would be especially important on systems where the
> BIOS/UEFI environment offers no option to toggle back the AHCI mode.
> This "RAID" Intel features is also known as "Intel Premium RST mode"
> on all current Clevo systems, and on such a platform (the Clevo
> P751DM2-G, marketed by the likes of Schenker and Origin PC) is based
> on this platform.
>
> -Dennis.
>
> On 10 November 2017 at 16:19, Christoph Hellwig <hch@infradead.org> wrote:
>> On Thu, Nov 09, 2017 at 10:24:54AM -0800, David F. wrote:
>>> It seems that Linux will not see any HD on Intel's 100 Series or newer
>>> chipsets (Z170, etc.) when in RAID mode. (typically these systems
>>> have M2 NVMe devices ). This is problematic when wanting to use Linux
>>> on the system without having to disable RAID and when on their with
>>> Windows. Maybe not a linux-raid issue, but is Linux RAID issue
>>> within the kernel device support.
>>
>> Dan (on Cc) posted some patches to support the awkwared so called
>> "RAID" mode (it really should be Intel landgrab mode) in the client
>> chipsets more than a year ago.
>>
>> It needed a bit of a rework to be present as a fake PCIe root port
>> instead of the platform driver magic, so I wonder what happened to
>> it - Dan any chance to get back to it?
>>
>> _______________________________________________
>> Linux-nvme mailing list
>> Linux-nvme@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* [PATCH v1] ata: sata_dwc_460ex: Propagate platform device ID to DMA driver
From: Andy Shevchenko @ 2017-11-10 17:59 UTC (permalink / raw)
To: Tejun Heo, linux-ide; +Cc: Andy Shevchenko
Propagate platform device ID to DMA driver to distinguish relationship
between DMA and SATA instances.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/ata/sata_dwc_460ex.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c
index ce128d5a6ded..6af4ec3c88c3 100644
--- a/drivers/ata/sata_dwc_460ex.c
+++ b/drivers/ata/sata_dwc_460ex.c
@@ -248,6 +248,7 @@ static int sata_dwc_dma_init_old(struct platform_device *pdev,
return -ENOMEM;
hsdev->dma->dev = &pdev->dev;
+ hsdev->dma->id = pdev->id;
/* Get SATA DMA interrupt number */
hsdev->dma->irq = irq_of_parse_and_map(np, 1);
--
2.14.2
^ permalink raw reply related
* Re: When will Linux support new RAID controllers
From: Dennis Mungai @ 2017-11-10 13:31 UTC (permalink / raw)
To: Christoph Hellwig
Cc: David F., linux-raid@vger.kernel.org, linux-ide, Dan Williams,
linux-nvme
In-Reply-To: <20171110131937.GA26181@infradead.org>
That feature would be especially important on systems where the
BIOS/UEFI environment offers no option to toggle back the AHCI mode.
This "RAID" Intel features is also known as "Intel Premium RST mode"
on all current Clevo systems, and on such a platform (the Clevo
P751DM2-G, marketed by the likes of Schenker and Origin PC) is based
on this platform.
-Dennis.
On 10 November 2017 at 16:19, Christoph Hellwig <hch@infradead.org> wrote:
> On Thu, Nov 09, 2017 at 10:24:54AM -0800, David F. wrote:
>> It seems that Linux will not see any HD on Intel's 100 Series or newer
>> chipsets (Z170, etc.) when in RAID mode. (typically these systems
>> have M2 NVMe devices ). This is problematic when wanting to use Linux
>> on the system without having to disable RAID and when on their with
>> Windows. Maybe not a linux-raid issue, but is Linux RAID issue
>> within the kernel device support.
>
> Dan (on Cc) posted some patches to support the awkwared so called
> "RAID" mode (it really should be Intel landgrab mode) in the client
> chipsets more than a year ago.
>
> It needed a bit of a rework to be present as a fake PCIe root port
> instead of the platform driver magic, so I wonder what happened to
> it - Dan any chance to get back to it?
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* Re: When will Linux support new RAID controllers
From: Christoph Hellwig @ 2017-11-10 13:19 UTC (permalink / raw)
To: David F.; +Cc: linux-raid@vger.kernel.org, linux-ide, linux-nvme, Dan Williams
In-Reply-To: <CAGRSmLs-Hr+FFfa4_29kidEeL2d7b+cEP6u1OkOUoYW6Cm15BA@mail.gmail.com>
On Thu, Nov 09, 2017 at 10:24:54AM -0800, David F. wrote:
> It seems that Linux will not see any HD on Intel's 100 Series or newer
> chipsets (Z170, etc.) when in RAID mode. (typically these systems
> have M2 NVMe devices ). This is problematic when wanting to use Linux
> on the system without having to disable RAID and when on their with
> Windows. Maybe not a linux-raid issue, but is Linux RAID issue
> within the kernel device support.
Dan (on Cc) posted some patches to support the awkwared so called
"RAID" mode (it really should be Intel landgrab mode) in the client
chipsets more than a year ago.
It needed a bit of a rework to be present as a fake PCIe root port
instead of the platform driver magic, so I wonder what happened to
it - Dan any chance to get back to it?
^ permalink raw reply
* Re: [cdrom_check_status] BUG: unable to handle kernel NULL pointer dereference at 000001c0
From: Bartlomiej Zolnierkiewicz @ 2017-11-08 18:09 UTC (permalink / raw)
To: Fengguang Wu
Cc: linux-ide, Borislav Petkov, David S. Miller, Linus Torvalds,
Jens Axboe, Bart Van Assche, linux-kernel
In-Reply-To: <7885793.0mqNGdeUvE@amdc3058>
On Wednesday, November 08, 2017 05:28:16 PM Bartlomiej Zolnierkiewicz wrote:
> Something is very wrong here as pci_request_selected_regions() in
> drivers/ide/setup-pci.c:ide_pci_enable() should allocate PCI resources
> so the second probe attempt should not happen. Also interface/device
> names reuse should be prevented by ide_find_port_slot()..
OK, I see now what is going on here:
...
CONFIG_DEBUG_TEST_DRIVER_REMOVE=y
...
config DEBUG_TEST_DRIVER_REMOVE
bool "Test driver remove calls during probe (UNSTABLE)"
depends on DEBUG_KERNEL
help
Say Y here if you want the Driver core to test driver remove functions
by calling probe, remove, probe. This tests the remove path without
having to unbind the driver or unload the driver module.
This option is expected to find errors and may render your system
unusable. You should say N here unless you are explicitly looking to
test this functionality.
We actually see race on ->remove inside IDE's ide-cd.c driver related to
disk_check_events() handling..
It is not worth to continue with fixing IDE but from the quick look SCSI
sr.c may have similar problem - it may be worth to try to reproduce it
using libata's piix driver (disable CONFIG_IDE and enable CONFIG_BLK_DEV_SR,
CONFIG_ATA_PIIX is already enabled).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* Re: [cdrom_check_status] BUG: unable to handle kernel NULL pointer dereference at 000001c0
From: Bartlomiej Zolnierkiewicz @ 2017-11-08 16:50 UTC (permalink / raw)
To: Fengguang Wu
Cc: linux-ide, Borislav Petkov, David S. Miller, Linus Torvalds,
Jens Axboe, Bart Van Assche, linux-kernel
In-Reply-To: <7885793.0mqNGdeUvE@amdc3058>
On Wednesday, November 08, 2017 05:28:16 PM Bartlomiej Zolnierkiewicz wrote:
> we can see that for some reason PIIX PCI IDE controller is probed
> twice and later when we attach ide-cd driver to both instances of hdc
> (in parallel) it ends up badly..
Actually it ends up badly later (I don't know exactly yet how we get
into this situation but this is not that important as we know that
the root problem starts much earlier with the double probe of PCI IDE
host controller)..
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* Re: [cdrom_check_status] BUG: unable to handle kernel NULL pointer dereference at 000001c0
From: Bartlomiej Zolnierkiewicz @ 2017-11-08 16:28 UTC (permalink / raw)
To: Fengguang Wu
Cc: linux-ide, Borislav Petkov, David S. Miller, Linus Torvalds,
Jens Axboe, Bart Van Assche, linux-kernel
In-Reply-To: <20171107102538.mzbfdxll3fpf2kqg@wfg-t540p.sh.intel.com>
On Tuesday, November 07, 2017 06:25:38 PM Fengguang Wu wrote:
> Hello,
Hi Fengguang,
> FYI this happens in v4.14-rc8 -- it's not necessarily a new bug.
>
> [ 22.626306] ide-cd: hdc: ATAPI 4X DVD-ROM drive, 512kB Cache
> [ 22.627216] cdrom: Uniform CD-ROM driver Revision: 3.20
> [ 22.638941] ide-cd: hdc: ATAPI 4X DVD-ROM drive, 512kB Cache
> [ 22.665149] rdac: device handler registered
> [ 22.666646] ACPI: Preparing to enter system sleep state S5
> [ 22.666764] BUG: unable to handle kernel NULL pointer dereference at 000001c0
> [ 22.666773] IP: cdrom_check_status+0x2c/0x90
> [ 22.666774] *pde = 00000000
> [ 22.666777] Oops: 0000 [#1] SMP
> [ 22.666782] CPU: 1 PID: 155 Comm: kworker/1:2 Not tainted 4.14.0-rc8 #127
> [ 22.666783] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
> [ 22.666788] Workqueue: events_freezable_power_ disk_events_workfn
> [ 22.666790] task: 4fe90980 task.stack: 507ac000
> [ 22.666792] EIP: cdrom_check_status+0x2c/0x90
> [ 22.666793] EFLAGS: 00210246 CPU: 1
> [ 22.666795] EAX: 00000000 EBX: 4fefec00 ECX: 00000000 EDX: 00000000
> [ 22.666796] ESI: 00000003 EDI: ffffffff EBP: 467a9340 ESP: 507aded0
> [ 22.666797] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> [ 22.666799] CR0: 80050033 CR2: 000001c0 CR3: 06e0f000 CR4: 00000690
> [ 22.666803] Call Trace:
> [ 22.666807] ? ide_cdrom_check_events_real+0x1d/0x40
> [ 22.666811] ? cdrom_check_events+0xe/0x30
> [ 22.666813] ? disk_check_events+0x3a/0xf0
> [ 22.666817] ? process_one_work+0x16a/0x370
> [ 22.666818] ? process_one_work+0x117/0x370
> [ 22.666820] ? worker_thread+0x31/0x3b0
> [ 22.666822] ? kthread+0xd7/0x110
> [ 22.666824] ? process_one_work+0x370/0x370
> [ 22.666826] ? __kthread_create_on_node+0x160/0x160
> [ 22.666830] ? ret_from_fork+0x19/0x30
> [ 22.666831] Code: 53 83 ec 14 89 c3 89 d1 be 03 00 00 00 65 a1 14 00 00 00 89 44 24 10 31 c0 8b 43 18 c7 44 24 04 00 00 00 00 c7 04 24 00 00 00 00 <8a> 80 c0 01 00 00 c7 44 24 08 00 00 00 00 83 e0 03 c7 44 24 0c
> [ 22.666863] EIP: cdrom_check_status+0x2c/0x90 SS:ESP: 0068:507aded0
> [ 22.666863] CR2: 00000000000001c0
> [ 22.666870] ---[ end trace 2410e586dd8f88b2 ]---
> [ 22.666872] Kernel panic - not syncing: Fatal exception
>
> Attached the full dmesg and kconfig.
>From the dmesg:
[ 18.372398] Uniform Multi-Platform E-IDE driver
[ 18.373507] piix 0000:00:01.1: IDE controller (0x8086:0x7010 rev 0x00)
[ 18.374773] piix 0000:00:01.1: not 100% native mode: will probe irqs later
[ 18.376676] ide0: BM-DMA at 0xc080-0xc087
[ 18.377411] ide1: BM-DMA at 0xc088-0xc08f
[ 18.378121] Probing IDE interface ide0...
[... (rcu stuff done in parallel)]
[ 18.984203] Probing IDE interface ide1...
[ 19.772269] hdc: QEMU DVD-ROM, ATAPI CD/DVD-ROM drive
[ 20.492253] hdc: host max PIO4 wanted PIO255(auto-tune) selected PIO0
[ 20.493396] hdc: MWDMA2 mode selected
[ 20.494219] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
[ 20.495001] ide1 at 0x170-0x177,0x376 on irq 15
[ 20.497649] piix 0000:00:01.1: IDE controller (0x8086:0x7010 rev 0x00)
[ 20.498835] piix 0000:00:01.1: not 100% native mode: will probe irqs later
[ 20.500931] ide0: BM-DMA at 0xc080-0xc087
[ 20.501669] ide1: BM-DMA at 0xc088-0xc08f
[ 20.502354] Probing IDE interface ide0...
[ 21.112206] Probing IDE interface ide1...
[ 21.900269] hdc: QEMU DVD-ROM, ATAPI CD/DVD-ROM drive
[ 22.620257] hdc: host max PIO4 wanted PIO255(auto-tune) selected PIO0
[ 22.621356] hdc: MWDMA2 mode selected
[ 22.622168] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
[ 22.622947] ide1 at 0x170-0x177,0x376 on irq 15
[ 22.624740] ide-gd driver 1.18
[ 22.625274] ide-cd driver 5.00
[ 22.626306] ide-cd: hdc: ATAPI 4X DVD-ROM drive, 512kB Cache
[ 22.627216] cdrom: Uniform CD-ROM driver Revision: 3.20
[ 22.638941] ide-cd: hdc: ATAPI 4X DVD-ROM drive, 512kB Cache
[ 22.665149] rdac: device handler registered
[ 22.666646] ACPI: Preparing to enter system sleep state S5
[ 22.666764] BUG: unable to handle kernel NULL pointer dereference at 000001c0
we can see that for some reason PIIX PCI IDE controller is probed
twice and later when we attach ide-cd driver to both instances of hdc
(in parallel) it ends up badly..
Something is very wrong here as pci_request_selected_regions() in
drivers/ide/setup-pci.c:ide_pci_enable() should allocate PCI resources
so the second probe attempt should not happen. Also interface/device
names reuse should be prevented by ide_find_port_slot()..
Does the dmesg for the good boot also contain double probe?
If not, can you add some debug to pci_request_selected_regions()?
[ I've seen Linus' opinion but it doesn't seem that IDE is a root
cause of the problem that we are seeing here.. ]
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* Re: [PATCH] drivers/ide-cd: Handle missing driver data during status check gracefully
From: David Miller @ 2017-11-08 0:08 UTC (permalink / raw)
To: torvalds; +Cc: bp, fengguang.wu, linux-ide, axboe, bart.vanassche, linux-kernel
In-Reply-To: <CA+55aFy+peFp-u753gu43L5eisPE8g-P_eCyx-amoBADm-k0NA@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 7 Nov 2017 09:13:04 -0800
> On Tue, Nov 7, 2017 at 8:37 AM, Borislav Petkov <bp@alien8.de> wrote:
>>
>> Here it is:
>
> Thanks, applied directly.
Thanks for taking care of this.
^ permalink raw reply
* Re: [PATCH] drivers/ide-cd: Handle missing driver data during status check gracefully
From: Linus Torvalds @ 2017-11-07 17:13 UTC (permalink / raw)
To: Borislav Petkov
Cc: Fengguang Wu, IDE-ML, David S. Miller, Jens Axboe,
Bart Van Assche, Linux Kernel Mailing List
In-Reply-To: <20171107163723.7u5iyvewrrjglqif@pd.tnic>
On Tue, Nov 7, 2017 at 8:37 AM, Borislav Petkov <bp@alien8.de> wrote:
>
> Here it is:
Thanks, applied directly.
Linus
^ permalink raw reply
* [PATCH] drivers/ide-cd: Handle missing driver data during status check gracefully
From: Borislav Petkov @ 2017-11-07 16:37 UTC (permalink / raw)
To: Linus Torvalds
Cc: Fengguang Wu, IDE-ML, David S. Miller, Jens Axboe,
Bart Van Assche, Linux Kernel Mailing List
In-Reply-To: <CA+55aFxBEMsrqTPOST18iQ_VwNkFxqWq744W74M+8VVT2eL-3w@mail.gmail.com>
On Tue, Nov 07, 2017 at 08:01:10AM -0800, Linus Torvalds wrote:
> Because this is not really worth spending a ton of effort on debugging
> (.. because IDE), but yes, the disassembly of the code clearly shows
> that the problem here is that 'info' is NULL.
Right.
> So adding the NULL guard and saying "we have a race somewhere in the
> IDE layer" and not wasting any more time on it is almost certainly the
> right thing to do.
I tried to reflect that situation in the commit message.
> Borislav, mind sending a signed-off patch or a pull request or whatever?
Here it is:
---
From: Borislav Petkov <bp@suse.de>
Subject: [PATCH] drivers/ide-cd: Handle missing driver data during status check gracefully
The 0day bot reports the below failure which happens occasionally, with
their randconfig testing (once every ~100 boots). The Code points at the
private pointer ->driver_data being NULL, which hints at a race of sorts
where the private driver_data descriptor has disappeared by the time we
get to run the workqueue.
So let's check that pointer before we continue with issuing the command
to the drive.
This fix is of the brown paper bag nature but considering that IDE is
long deprecated, let's do that so that random testing which happens to
enable CONFIG_IDE during randconfig builds, doesn't fail because of
this.
Besides, failing the TEST_UNIT_READY command because the drive private
data is gone is something which we could simply do anyway, to denote
that there was a problem communicating with the device.
BUG: unable to handle kernel NULL pointer dereference at 000001c0
IP: cdrom_check_status
*pde = 00000000
Oops: 0000 [#1] SMP
CPU: 1 PID: 155 Comm: kworker/1:2 Not tainted 4.14.0-rc8 #127
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
Workqueue: events_freezable_power_ disk_events_workfn
task: 4fe90980 task.stack: 507ac000
EIP: cdrom_check_status+0x2c/0x90
EFLAGS: 00210246 CPU: 1
EAX: 00000000 EBX: 4fefec00 ECX: 00000000 EDX: 00000000
ESI: 00000003 EDI: ffffffff EBP: 467a9340 ESP: 507aded0
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 80050033 CR2: 000001c0 CR3: 06e0f000 CR4: 00000690
Call Trace:
? ide_cdrom_check_events_real
? cdrom_check_events
? disk_check_events
? process_one_work
? process_one_work
? worker_thread
? kthread
? process_one_work
? __kthread_create_on_node
? ret_from_fork
Code: 53 83 ec 14 89 c3 89 d1 be 03 00 00 00 65 a1 14 00 00 00 89 44 24 10 31 c0 8b 43 18 c7 44 24 04 00 00 00 00 c7 04 24 00 00 00 00 <8a> 80 c0 01 00 00 c7 44 24 08 00 00 00 00 83 e0 03 c7 44 24 0c
EIP: cdrom_check_status+0x2c/0x90 SS:ESP: 0068:507aded0
CR2: 00000000000001c0
---[ end trace 2410e586dd8f88b2 ]---
Reported-and-tested-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Bart Van Assche <bart.vanassche@sandisk.com>
---
drivers/ide/ide-cd.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index a7355ab3bb22..6ff0be8cbdc9 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -867,11 +867,16 @@ static void msf_from_bcd(struct atapi_msf *msf)
int cdrom_check_status(ide_drive_t *drive, struct request_sense *sense)
{
struct cdrom_info *info = drive->driver_data;
- struct cdrom_device_info *cdi = &info->devinfo;
+ struct cdrom_device_info *cdi;
unsigned char cmd[BLK_MAX_CDB];
ide_debug_log(IDE_DBG_FUNC, "enter");
+ if (!info)
+ return -EIO;
+
+ cdi = &info->devinfo;
+
memset(cmd, 0, BLK_MAX_CDB);
cmd[0] = GPCMD_TEST_UNIT_READY;
--
2.13.0
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply related
* Re: [cdrom_check_status] BUG: unable to handle kernel NULL pointer dereference at 000001c0
From: Fengguang Wu @ 2017-11-07 16:34 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-ide, David S. Miller, Linus Torvalds, Jens Axboe,
Bart Van Assche, linux-kernel
In-Reply-To: <20171107140102.n2pncsaer5o5hmt7@pd.tnic>
On Tue, Nov 07, 2017 at 03:01:02PM +0100, Borislav Petkov wrote:
>On Tue, Nov 07, 2017 at 09:06:26PM +0800, Fengguang Wu wrote:
>> It turns out rather hard to reproduce -- that's the only occurrence in
>> 100 boots. Perhaps we'll have to give up on this.
>
>Right,
>
>you could blacklist CONFIG_IDE from your randconfig testing - IDE has
>been going away since forever :-)
>
>Alternatively, we could brown-paper bag it with something like this:
Tested-by: Fengguang Wu <fengguang.wu@intel.com>
I managed to reproduce the issue ~10 times with 500+ boots.
With this fix applied, the BUG no longer shows up in so many boots.
Thanks,
Fengguang
>---
>diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
>index a7355ab3bb22..6ff0be8cbdc9 100644
>--- a/drivers/ide/ide-cd.c
>+++ b/drivers/ide/ide-cd.c
>@@ -867,11 +867,16 @@ static void msf_from_bcd(struct atapi_msf *msf)
> int cdrom_check_status(ide_drive_t *drive, struct request_sense *sense)
> {
> struct cdrom_info *info = drive->driver_data;
>- struct cdrom_device_info *cdi = &info->devinfo;
>+ struct cdrom_device_info *cdi;
> unsigned char cmd[BLK_MAX_CDB];
>
> ide_debug_log(IDE_DBG_FUNC, "enter");
>
>+ if (!info)
>+ return -EIO;
>+
>+ cdi = &info->devinfo;
>+
> memset(cmd, 0, BLK_MAX_CDB);
> cmd[0] = GPCMD_TEST_UNIT_READY;
>--
>
>but from looking at this (I had forgotten how, hm, "interesting" the
>IDE code was :-)) it looks like some sort of a race where we've called
>->release earlier and drive->driver_data is gone by the time the
>workqueue function runs. Or something to that effect...
>
>Anyway, you can still give me your qemu command line and I can try to
>debug it, if you'd like. But yeah, it would probably be a waste of time
>as IDE is long deprecated...
>
>Thx.
>
>--
>Regards/Gruss,
> Boris.
>
>Good mailing practices for 400: avoid top-posting and trim the reply.
>
^ permalink raw reply
* Re: [cdrom_check_status] BUG: unable to handle kernel NULL pointer dereference at 000001c0
From: Bart Van Assche @ 2017-11-07 16:29 UTC (permalink / raw)
To: fengguang.wu@intel.com, linux-ide@vger.kernel.org
Cc: torvalds@linux-foundation.org, davem@davemloft.net,
linux-kernel@vger.kernel.org, Bart Van Assche, bp@alien8.de,
axboe@kernel.dk
In-Reply-To: <20171107102538.mzbfdxll3fpf2kqg@wfg-t540p.sh.intel.com>
On Tue, 2017-11-07 at 18:25 +0800, Fengguang Wu wrote:
> [ 22.666764] BUG: unable to handle kernel NULL pointer dereference at 000001c0
> [ 22.666773] IP: cdrom_check_status+0x2c/0x90
If it is a regression then this patch might fix this kernel oops:
https://www.mail-archive.com/linux-block@vger.kernel.org/msg15155.html
Bart.
^ permalink raw reply
* Re: [cdrom_check_status] BUG: unable to handle kernel NULL pointer dereference at 000001c0
From: Linus Torvalds @ 2017-11-07 16:01 UTC (permalink / raw)
To: Borislav Petkov
Cc: Fengguang Wu, IDE-ML, David S. Miller, Jens Axboe,
Bart Van Assche, Linux Kernel Mailing List
In-Reply-To: <20171107140102.n2pncsaer5o5hmt7@pd.tnic>
On Tue, Nov 7, 2017 at 6:01 AM, Borislav Petkov <bp@alien8.de> wrote:
>
> Alternatively, we could brown-paper bag it with something like this:
This looks like a good thing to do regardless..
Because this is not really worth spending a ton of effort on debugging
(.. because IDE), but yes, the disassembly of the code clearly shows
that the problem here is that 'info' is NULL.
So adding the NULL guard and saying "we have a race somewhere in the
IDE layer" and not wasting any more time on it is almost certainly the
right thing to do.
Borislav, mind sending a signed-off patch or a pull request or whatever?
Linus
^ 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