Add support for a new method for BIOS to provide the address and length
of the protected SMI communication buffer, via SMBIOS OEM strings.
Signed-off-by: Stuart Hayes
---
drivers/platform/x86/dcdbas.c | 43 ---
1 file changed, 30 insertions(+), 13 deletions
On 10/21/19 8:47 AM, Mika Westerberg wrote:
> On Thu, Oct 17, 2019 at 03:32:56PM -0400, Stuart Hayes wrote:
>> Some systems have in-band presence detection disabled for hot-plug PCI
>> slots, but do not report this in the slot capabilities 2 (SLTCAP2) register.
>> On th
On 10/21/19 8:41 AM, Mika Westerberg wrote:
> On Thu, Oct 17, 2019 at 03:32:55PM -0400, Stuart Hayes wrote:
>> From: Alexandru Gagniuc
>>
>> When inband presence is disabled, PDS may come up at any time, or not
>> at all. PDS being low may indicate that the card
the device is enabled.
Signed-off-by: Alexandru Gagniuc
Signed-off-by: Stuart Hayes
---
v2:
replace while(true) loop with do...while
v3
remove unused variable declaration (pds)
modify text of warning message
drivers/pci/hotplug/pciehp_hpc.c | 19 +++
1 file changed, 19
From: Alexandru Gagniuc
The presence detect state (PDS) is normally a logical or of in-band and
out-of-band presence. As of PCIe 4.0, there is the option to disable
in-band presence so that the PDS bit always reflects the state of the
out-of-band presence.
The recommendation of the PCIe spec is
or disabling in-band presence
PCI: pciehp: Wait for PDS if in-band presence is disabled
Stuart Hayes (1):
PCI: pciehp: Add dmi table for in-band presence disabled
drivers/pci/hotplug/pciehp.h | 1 +
drivers/pci/hotplug/pciehp_hpc.c | 45 +++-
include/uapi/linu
a
device is connected.
Add a dmi table to flag these systems as having in-band presence disabled.
Signed-off-by: Stuart Hayes
---
drivers/pci/hotplug/pciehp_hpc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
patchwork.kernel.org/cover/10909167/
[v3,0/4] PCI: pciehp: Do not turn off slot if presence comes up after link
v2:
- modify loop in pcie_wait_for_presence to do..while
Alexandru Gagniuc (2):
PCI: pciehp: Add support for disabling in-band presence
PCI: pciehp: Wait for PDS if in-band presence
the device is enabled.
Signed-off-by: Alexandru Gagniuc
Signed-off-by: Stuart Hayes
---
v2:
replace while(true) loop with do...while
drivers/pci/hotplug/pciehp_hpc.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug
a
device is connected.
Add a dmi table to flag these systems as having in-band presence disabled.
Signed-off-by: Stuart Hayes
---
drivers/pci/hotplug/pciehp_hpc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
From: Alexandru Gagniuc
The presence detect state (PDS) is normally a logical or of in-band and
out-of-band presence. As of PCIe 4.0, there is the option to disable
in-band presence so that the PDS bit always reflects the state of the
out-of-band presence.
The recommendation of the PCIe spec is
On Thu, Oct 10, 2019 at 12:40 AM Andy Shevchenko
wrote:
>
> On Thu, Oct 10, 2019 at 8:37 AM Andy Shevchenko
> wrote:
> > On Wed, Oct 9, 2019 at 11:05 PM Stuart Hayes
> > wrote:
>
> > > +static void pcie_wait_for_presence(struct pci_dev *pdev)
> >
the device is enabled.
Signed-off-by: Alexandru Gagniuc
Signed-off-by: Stuart Hayes
---
drivers/pci/hotplug/pciehp_hpc.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index dc109d521f30..1282641c6458
a
device is connected.
Add a dmi table to flag these systems as having in-band presence disabled.
Signed-off-by: Stuart Hayes
---
drivers/pci/hotplug/pciehp_hpc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
From: Alexandru Gagniuc
The presence detect state (PDS) is normally a logical or of in-band and
out-of-band presence. As of PCIe 4.0, there is the option to disable
in-band presence so that the PDS bit always reflects the state of the
out-of-band presence.
The recommendation of the PCIe spec is
patchwork.kernel.org/cover/10909167/
[v3,0/4] PCI: pciehp: Do not turn off slot if presence comes up after link
Alexandru Gagniuc (2):
PCI: pciehp: Add support for disabling in-band presence
PCI: pciehp: Wait for PDS if in-band presence is disabled
Stuart Hayes (1):
PCI: pciehp: Add d
On Tue, Oct 1, 2019 at 11:13 PM Lukas Wunner wrote:
>
> On Tue, Oct 01, 2019 at 05:14:16PM -0400, Stuart Hayes wrote:
> > This patch set is based on a patch set [1] submitted many months ago by
> > Alexandru Gagniuc, who is no longer working on it.
> >
> > [1] http
On Tue, Oct 1, 2019 at 4:36 PM Alex G. wrote:
>
>
>
> On 10/1/19 4:14 PM, Stuart Hayes wrote:
> > Some systems have in-band presence detection disabled for hot-plug PCI
> > slots,
> > but do not report this in the slot capabilities 2 (SLTCAP2) register. On
> >
a
device is connected.
Add a dmi table to flag these systems as having in-band presence disabled.
Signed-off-by: Stuart Hayes
---
drivers/pci/hotplug/pciehp_hpc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
comes up after link
Stuart Hayes (3):
PCI: pciehp: Add support for disabling in-band presence
PCI: pciehp: Wait for PDS when in-band presence is disabled
PCI: pciehp: Add dmi table for systems with in-band presence disabled
drivers/pci/hotplug/pciehp.h | 1 +
drivers/pci/hotpl
.
Signed-off-by: Stuart Hayes
---
drivers/pci/hotplug/pciehp_hpc.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index dc109d521f30..1282641c6458 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers
presence
whenever supported.
Signed-off-by: Stuart Hayes
---
drivers/pci/hotplug/pciehp.h | 1 +
drivers/pci/hotplug/pciehp_hpc.c | 9 -
include/uapi/linux/pci_regs.h| 2 ++
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/hotplug/pciehp.h b/drivers/pci/hotplug
Tested on a Dell PowerEdge R7425 system on which this problem is easily
reproducible.
Tested-by: Stuart Hayes
Tested on a Dell PowerEdge R7425 system on which this problem is easily
reproducible.
Tested-by: Stuart Hayes
T))
> return -EINVAL; /* can't happen per definition */
>
> - spin_lock(_data.lock);
> rbu_data.image_update_buffer = image_update_buffer;
> rbu_data.image_update_buffer_size = size;
> rbu_data.bios_image_size = rbu_data.image_update_buffer_size;
>
Acked-by: Stuart Hayes
return -EINVAL; /* can't happen per defintion */
> +
> + spin_lock(_data.lock);
> + rbu_data.image_update_buffer = image_update_buffer;
> + rbu_data.image_update_buffer_size = size;
> + rbu_data.bios_image_size = rbu_data.image_update_buffer_size;
> + rbu_data.image_update_ordernum = ordernum;
> + return 0;
> }
>
> static ssize_t read_packet_data(char *buffer, loff_t pos, size_t count)
>
Acked-by: Stuart Hayes
Move dell_rbu to the more appropriate directory drivers/platform/x86.
Signed-off-by: Stuart Hayes
---
v2 changes:
- add commit message
drivers/firmware/Kconfig | 12
drivers/firmware/Makefile | 1 -
drivers/platform/x86/Kconfig
Move dcdbas to the more appropriate directory drivers/platform/x86.
Signed-off-by: Stuart Hayes
---
v2 changes:
- add commit message
drivers/firmware/Kconfig| 16
drivers/firmware/Makefile | 1 -
drivers/platform/x86/Kconfig
Move dcdbas to the more appropriate directory drivers/platform/x86.
Signed-off-by: Stuart Hayes
---
v2 changes:
- add commit message
drivers/firmware/Kconfig| 16
drivers/firmware/Makefile | 1 -
drivers/platform/x86/Kconfig
Move dell_rbu to the more appropriate directory drivers/platform/x86.
Signed-off-by: Stuart Hayes
---
v2 changes:
- add commit message
drivers/firmware/Kconfig | 12
drivers/firmware/Makefile | 1 -
drivers/platform/x86/Kconfig
(CPU
cache contents are lost on reboot).
With this patch, the payload memory will be changed to uncachable to ensure
that the payload is actually in main memory before the system is rebooted.
Signed-off-by: Stuart Hayes
---
This patch has been discussed previously, see history at
https
(CPU
cache contents are lost on reboot).
With this patch, the payload memory will be changed to uncachable to ensure
that the payload is actually in main memory before the system is rebooted.
Signed-off-by: Stuart Hayes
---
This patch has been discussed previously, see history at
https
Assign maintainer for dell_rbu driver, and reassign maintainer of dcdbas
from inactive maintainer (current maintainer is aware of this change--
see https://www.spinics.net/lists/platform-driver-x86/msg16336.html).
Signed-off-by: Stuart Hayes
Acked-by: Doug Warzecha
---
v2 changes:
- remove
Assign maintainer for dell_rbu driver, and reassign maintainer of dcdbas
from inactive maintainer (current maintainer is aware of this change--
see https://www.spinics.net/lists/platform-driver-x86/msg16336.html).
Signed-off-by: Stuart Hayes
Acked-by: Doug Warzecha
---
v2 changes:
- remove
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
---
This patch has been discussed
- remove extra whitespace in MAINTAINERS
- add acked-by from (previous) maintainer of dcdbas
Stuart Hayes (5):
firmware: dell_rbu: Make payload memory uncachable
firmware: dcdbas: Add support for WSMT ACPI table
firmware: dell_rbu: Move dell_rbu to drivers/platform/x86
firmware: dcdbas: Move
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
---
This patch has been discussed
- remove extra whitespace in MAINTAINERS
- add acked-by from (previous) maintainer of dcdbas
Stuart Hayes (5):
firmware: dell_rbu: Make payload memory uncachable
firmware: dcdbas: Add support for WSMT ACPI table
firmware: dell_rbu: Move dell_rbu to drivers/platform/x86
firmware: dcdbas: Move
From: Stuart Hayes
Signed-off-by: Stuart Hayes
---
drivers/firmware/Kconfig | 12
drivers/firmware/Makefile | 1 -
drivers/platform/x86/Kconfig | 12
drivers/platform/x86/Makefile | 1
From: Stuart Hayes
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
---
This patch
From: Stuart Hayes
The dell_rbu and dcdbas drivers need some changes, and should be moved to
drivers/platform/x86. Additionally, dell_rbu needs a maintainer, and the
listed maintainer for dcdbas is inactive and needs to be changed.
Stuart Hayes (5):
firmware: dell_rbu: Make payload memory
From: Stuart Hayes
Assign maintainer for dell_rbu driver, and reassign maintainer of dcdbas
from inactive maintainer (current maintainer is aware of this change--
see https://www.spinics.net/lists/platform-driver-x86/msg16336.html).
Signed-off-by: Stuart Hayes
---
MAINTAINERS | 11
From: Stuart Hayes
The dell_rbu driver takes firmware update payloads and puts them in memory so
the system BIOS can find them after a reboot. This sometimes fails (though
rarely), because the memory containing the payload is in the CPU cache but
never gets written back to main memory before
From: Stuart Hayes
Signed-off-by: Stuart Hayes
---
drivers/firmware/Kconfig | 12
drivers/firmware/Makefile | 1 -
drivers/platform/x86/Kconfig | 12
drivers/platform/x86/Makefile | 1
From: Stuart Hayes
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
---
This patch
From: Stuart Hayes
The dell_rbu and dcdbas drivers need some changes, and should be moved to
drivers/platform/x86. Additionally, dell_rbu needs a maintainer, and the
listed maintainer for dcdbas is inactive and needs to be changed.
Stuart Hayes (5):
firmware: dell_rbu: Make payload memory
From: Stuart Hayes
Assign maintainer for dell_rbu driver, and reassign maintainer of dcdbas
from inactive maintainer (current maintainer is aware of this change--
see https://www.spinics.net/lists/platform-driver-x86/msg16336.html).
Signed-off-by: Stuart Hayes
---
MAINTAINERS | 11
From: Stuart Hayes
The dell_rbu driver takes firmware update payloads and puts them in memory so
the system BIOS can find them after a reboot. This sometimes fails (though
rarely), because the memory containing the payload is in the CPU cache but
never gets written back to main memory before
From: Stuart Hayes
Signed-off-by: Stuart Hayes
---
drivers/firmware/Kconfig| 16
drivers/firmware/Makefile | 1 -
drivers/platform/x86/Kconfig| 16
drivers/platform/x86/Makefile | 1
From: Stuart Hayes
Signed-off-by: Stuart Hayes
---
drivers/firmware/Kconfig| 16
drivers/firmware/Makefile | 1 -
drivers/platform/x86/Kconfig| 16
drivers/platform/x86/Makefile | 1
(CPU
cache contents are lost on reboot).
With this patch, the payload memory will be changed to uncachable to ensure
that the payload is actually in main memory before the system is rebooted.
Signed-off-by: Stuart Hayes
Reviewed-by: Takashi Iwai
Signed-off-by: Takashi Iwai
---
v2 Added include
(CPU
cache contents are lost on reboot).
With this patch, the payload memory will be changed to uncachable to ensure
that the payload is actually in main memory before the system is rebooted.
Signed-off-by: Stuart Hayes
Reviewed-by: Takashi Iwai
Signed-off-by: Takashi Iwai
---
v2 Added include
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
---
v2 Bumped driver version
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
---
v2 Bumped driver version
On 7/2/2018 11:15 AM, mario.limoncie...@dell.com wrote:
>>
>>> I don't believe SMM communication ACPI table has ever been implemented by
>> Dell
>>> on server or client BIOS. I do agree this table describes the behavior
>>> that DCDBAS
>> driver
>>> has used since before even UEFI BIOS pretty
On 7/2/2018 11:15 AM, mario.limoncie...@dell.com wrote:
>>
>>> I don't believe SMM communication ACPI table has ever been implemented by
>> Dell
>>> on server or client BIOS. I do agree this table describes the behavior
>>> that DCDBAS
>> driver
>>> has used since before even UEFI BIOS pretty
On 06/27/2018 06:52 PM, Andy Shevchenko wrote:
> On Fri, Jun 15, 2018 at 1:31 AM, Stuart Hayes
> wrote:
>> On 6/14/2018 12:25 PM, Andy Shevchenko wrote:
>>> On Thu, Jun 14, 2018 at 5:22 PM, Stuart Hayes
>>> wrote:
>>>> O
On 06/27/2018 06:52 PM, Andy Shevchenko wrote:
> On Fri, Jun 15, 2018 at 1:31 AM, Stuart Hayes
> wrote:
>> On 6/14/2018 12:25 PM, Andy Shevchenko wrote:
>>> On Thu, Jun 14, 2018 at 5:22 PM, Stuart Hayes
>>> wrote:
>>>> O
On 6/14/2018 12:26 PM, Andy Shevchenko wrote:
> On Thu, Jun 14, 2018 at 6:45 PM, Stuart Hayes
> wrote:
>>
>> If the WSMT ACPI table is present and indicates that a fixed communication
>> buffer should be used, use the firmware-specified buffer instead of
>>
On 6/14/2018 12:26 PM, Andy Shevchenko wrote:
> On Thu, Jun 14, 2018 at 6:45 PM, Stuart Hayes
> wrote:
>>
>> If the WSMT ACPI table is present and indicates that a fixed communication
>> buffer should be used, use the firmware-specified buffer instead of
>>
On 6/14/2018 12:25 PM, Andy Shevchenko wrote:
> On Thu, Jun 14, 2018 at 5:22 PM, Stuart Hayes
> wrote:
>> On 6/13/2018 3:54 AM, Andy Shevchenko wrote:
>
>>>> +* Provide physical address of command buffer field within
>>>> +
On 6/14/2018 12:25 PM, Andy Shevchenko wrote:
> On Thu, Jun 14, 2018 at 5:22 PM, Stuart Hayes
> wrote:
>> On 6/13/2018 3:54 AM, Andy Shevchenko wrote:
>
>>>> +* Provide physical address of command buffer field within
>>>> +
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
---
v2 Bumped driver version
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
---
v2 Bumped driver version
On 6/13/2018 3:54 AM, Andy Shevchenko wrote:
>> + /* Calling Interface SMI
>
> I suppose the style of the comments like
> /*
> * Calling ...
> ...
Yes... goof on my part. Thanks.
>> +*
>> +* Provide physical address of command buffer field
On 6/13/2018 3:54 AM, Andy Shevchenko wrote:
>> + /* Calling Interface SMI
>
> I suppose the style of the comments like
> /*
> * Calling ...
> ...
Yes... goof on my part. Thanks.
>> +*
>> +* Provide physical address of command buffer field
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
---
v2 Bumped driver version
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
---
v2 Bumped driver version
On 6/8/2018 8:04 PM, Darren Hart wrote:
> On Thu, Jun 07, 2018 at 08:11:41PM +0300, Andy Shevchenko wrote:
>> On Thu, Jun 7, 2018 at 6:59 PM, Stuart Hayes
>> wrote:
>>> If the WSMT ACPI table is present and indicates that a fixed communication
>>> buffer
On 6/8/2018 8:04 PM, Darren Hart wrote:
> On Thu, Jun 07, 2018 at 08:11:41PM +0300, Andy Shevchenko wrote:
>> On Thu, Jun 7, 2018 at 6:59 PM, Stuart Hayes
>> wrote:
>>> If the WSMT ACPI table is present and indicates that a fixed communication
>>> buffer
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
Tested-by: Mario Limonciello
Acked
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
Tested-by: Mario Limonciello
Acked
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes <stuart.w.ha...@gmail.com>
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
---
v2 Bumped driver version to 5.6.0
On 4/18/2018 12:46 AM, Takashi Iwai wrote:
> From: Stuart Hayes <stuart.w.ha...@gmail.com>
>
> The dell_rbu driver takes firmware update payloads and puts them in memory so
> the system BIOS can find them after a reboot. This sometimes fails (though
> rarely), because
On 4/18/2018 12:46 AM, Takashi Iwai wrote:
> From: Stuart Hayes
>
> The dell_rbu driver takes firmware update payloads and puts them in memory so
> the system BIOS can find them after a reboot. This sometimes fails (though
> rarely), because the memory containing the payloa
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmware.
Signed-off-by: Stuart Hayes <stuart.w.ha...@gmail.com>
Re
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmware.
Signed-off-by: Stuart Hayes
Reviewed-by: Mario Limonciello
(CPU
cache contents are lost on reboot).
With this patch, the payload memory will be changed to uncachable to ensure
that the payload is actually in main memory before the system is rebooted.
Signed-off-by: Stuart Hayes <stuart.w.ha...@gmail.com>
---
v2 Added include, removed extra parenthe
(CPU
cache contents are lost on reboot).
With this patch, the payload memory will be changed to uncachable to ensure
that the payload is actually in main memory before the system is rebooted.
Signed-off-by: Stuart Hayes
---
v2 Added include, removed extra parentheses
v3 Corrected formatting
On 4/4/2018 3:30 PM, Takashi Iwai wrote:
> On Wed, 28 Mar 2018 17:07:47 +0200,
> Stuart Hayes wrote:
>>
>> @@ -180,6 +181,12 @@ static int create_packet(void *data, size_t length)
>> invalid_addr_packet_array[idx++
On 4/4/2018 3:30 PM, Takashi Iwai wrote:
> On Wed, 28 Mar 2018 17:07:47 +0200,
> Stuart Hayes wrote:
>>
>> @@ -180,6 +181,12 @@ static int create_packet(void *data, size_t length)
>> invalid_addr_packet_array[idx++
(CPU
cache contents are lost on reboot).
With this patch, the payload memory will be changed to uncachable to ensure
that the payload is actually in main memory before the system is rebooted.
Signed-off-by: Stuart Hayes <stuart.w.ha...@gmail.com>
---
v2 Added include, removed extra parenthe
(CPU
cache contents are lost on reboot).
With this patch, the payload memory will be changed to uncachable to ensure
that the payload is actually in main memory before the system is rebooted.
Signed-off-by: Stuart Hayes
---
v2 Added include, removed extra parentheses
v3 Corrected formatting
Please disregard this version. I'm sorry (and intensely embarrassed).
Please disregard this version. I'm sorry (and intensely embarrassed).
(CPU
cache contents are lost on reboot).
With this patch, the payload memory will be changed to uncachable to ensure
that the payload is actually in main memory before the system is rebooted.
Signed-off-by: Stuart Hayes <stuart.w.ha...@gmail.com>
---
v2 Added include, removed extra paren
(CPU
cache contents are lost on reboot).
With this patch, the payload memory will be changed to uncachable to ensure
that the payload is actually in main memory before the system is rebooted.
Signed-off-by: Stuart Hayes
---
v2 Added include, removed extra parentheses
This patch has no maintainer
please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Stuart-Hayes/dell_rbu-make-firmware-payload-memory-uncachable/20180323-094405
> config: i386-randconfig-x014-201811 (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
>
please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Stuart-Hayes/dell_rbu-make-firmware-payload-memory-uncachable/20180323-094405
> config: i386-randconfig-x014-201811 (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
>
(CPU
cache contents are lost on reboot).
With this patch, the payload memory will be changed to uncachable to ensure
that the payload is actually in main memory before the system is rebooted.
Signed-off-by: Stuart Hayes <stuart.w.ha...@gmail.com>
---
Note that there is no main
(CPU
cache contents are lost on reboot).
With this patch, the payload memory will be changed to uncachable to ensure
that the payload is actually in main memory before the system is rebooted.
Signed-off-by: Stuart Hayes
---
Note that there is no maintainer for this driver, so I'd be grateful
that
scsi_eh_scmd_add() also uses the spinlock.
I tested your patch on my issue, and it did indeed fix my issue.
So you can add...
Tested-by: Stuart Hayes <stuart.w.ha...@gmail.com>
Thanks
Stuart
On 11/21/2017 2:09 AM, Pavel Tikhomirov wrote:
> My patch should also fix your issue to
that
scsi_eh_scmd_add() also uses the spinlock.
I tested your patch on my issue, and it did indeed fix my issue.
So you can add...
Tested-by: Stuart Hayes
Thanks
Stuart
On 11/21/2017 2:09 AM, Pavel Tikhomirov wrote:
> My patch should also fix your issue too, please see explanation in re
Pavel,
It turns out that the error handler on our systems was not getting woken up for
a different reason... I submitted a patch earlier today that fixes the issue I
were seeing (I CCed you on the patch).
Before I got my hands on the failing system and was able to root cause it, I
was pretty
Pavel,
It turns out that the error handler on our systems was not getting woken up for
a different reason... I submitted a patch earlier today that fixes the issue I
were seeing (I CCed you on the patch).
Before I got my hands on the failing system and was able to root cause it, I
was pretty
When a command is added to the host's error handler command queue, there is a
chance that the error handler will not be woken up. This can happen when one
CPU is running scsi_eh_scmd_add() at the same time as another CPU is running
scsi_device_unbusy() for a different command on the same host.
When a command is added to the host's error handler command queue, there is a
chance that the error handler will not be woken up. This can happen when one
CPU is running scsi_eh_scmd_add() at the same time as another CPU is running
scsi_device_unbusy() for a different command on the same host.
Are there any issues with this patch
(https://patchwork.kernel.org/patch/9938919/) that Pavel Tikhomirov submitted
back in September? I am willing to help if there's anything I can do to help
get it accepted.
The failing case I'm working on involves lots of servers with disk read/write
Are there any issues with this patch
(https://patchwork.kernel.org/patch/9938919/) that Pavel Tikhomirov submitted
back in September? I am willing to help if there's anything I can do to help
get it accepted.
The failing case I'm working on involves lots of servers with disk read/write
1 - 100 of 130 matches
Mail list logo
