Re: sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

On Mon, Oct 16, 2017 at 4:11 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: > To recap: a dual-socket Xeon (E5 v4) server system had been running a > bunch of KVM workloads just fine for over 6 weeks. Suddenly hard > lockups occurred on cpu 13 in task_numa_migrate(), and cpu 0 in

Re: sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

On Mon, Oct 16, 2017 at 4:11 PM, Ed Swierk wrote: > To recap: a dual-socket Xeon (E5 v4) server system had been running a > bunch of KVM workloads just fine for over 6 weeks. Suddenly hard > lockups occurred on cpu 13 in task_numa_migrate(), and cpu 0 in > idle_balance(). That conditi

Re: sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

to reproduce the problem with an upstream kernel or any other, yet to my limited understanding of the evidence it appears there may indeed be a real problem lurking in there. I will follow up with the grsec folks. > On Thu, Nov 2, 2017 at 5:51 PM, Ed Swierk <eswi...@skyportsystems.com>

Re: sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

ream kernel or any other, yet to my limited understanding of the evidence it appears there may indeed be a real problem lurking in there. I will follow up with the grsec folks. > On Thu, Nov 2, 2017 at 5:51 PM, Ed Swierk wrote: >> Ping? >> >> On Wed, Oct 25, 2017 at 9:35

Re: sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

Ping? On Wed, Oct 25, 2017 at 9:35 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: > > Ping? > > On Mon, Oct 16, 2017 at 4:11 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: > > > > Ping for Peter, Ingo and other sched maintainers: > > > >

Re: sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

Ping? On Wed, Oct 25, 2017 at 9:35 PM, Ed Swierk wrote: > > Ping? > > On Mon, Oct 16, 2017 at 4:11 PM, Ed Swierk wrote: > > > > Ping for Peter, Ingo and other sched maintainers: > > > > I'd appreciate any feedback on this hard lockup issue, which occ

Re: sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

Ping? On Mon, Oct 16, 2017 at 4:11 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: > > Ping for Peter, Ingo and other sched maintainers: > > I'd appreciate any feedback on this hard lockup issue, which occurred > on a system running kernel 4.4.52-grsec. > > To re

Re: sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

Ping? On Mon, Oct 16, 2017 at 4:11 PM, Ed Swierk wrote: > > Ping for Peter, Ingo and other sched maintainers: > > I'd appreciate any feedback on this hard lockup issue, which occurred > on a system running kernel 4.4.52-grsec. > > To recap: a dual-socket Xeon (E5 v4) s

sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

Ping for Peter, Ingo and other sched maintainers: I'd appreciate any feedback on this hard lockup issue, which occurred on a system running kernel 4.4.52-grsec. To recap: a dual-socket Xeon (E5 v4) server system had been running a bunch of KVM workloads just fine for over 6 weeks. Suddenly hard

sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

Ping for Peter, Ingo and other sched maintainers: I'd appreciate any feedback on this hard lockup issue, which occurred on a system running kernel 4.4.52-grsec. To recap: a dual-socket Xeon (E5 v4) server system had been running a bunch of KVM workloads just fine for over 6 weeks. Suddenly hard

Re: Which came first, hard kernel lockup or SATA errors?

Continuing the conversation with the voices in my head... On Mon, Oct 9, 2017 at 10:45 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: > Based on the addresses in the stack and registers, here's what I think > happened. > > On cpu 13: > > - task_numa_fault() calls ta

Re: Which came first, hard kernel lockup or SATA errors?

Continuing the conversation with the voices in my head... On Mon, Oct 9, 2017 at 10:45 PM, Ed Swierk wrote: > Based on the addresses in the stack and registers, here's what I think > happened. > > On cpu 13: > > - task_numa_fault() calls task_numa_migrate(), which selects the

Re: Which came first, hard kernel lockup or SATA errors?

On Fri, Oct 6, 2017 at 6:25 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: > I'm trying to untangle a series of problems that suddenly occurred on > a dual-socket Xeon server system that had been running a bunch of KVM > workloads just fine for over 6 weeks (4.4.52-grsec k

Re: Which came first, hard kernel lockup or SATA errors?

On Fri, Oct 6, 2017 at 6:25 PM, Ed Swierk wrote: > I'm trying to untangle a series of problems that suddenly occurred on > a dual-socket Xeon server system that had been running a bunch of KVM > workloads just fine for over 6 weeks (4.4.52-grsec kernel, > Debian-derived userspace).

Which came first, hard kernel lockup or SATA errors?

I'm trying to untangle a series of problems that suddenly occurred on a dual-socket Xeon server system that had been running a bunch of KVM workloads just fine for over 6 weeks (4.4.52-grsec kernel, Debian-derived userspace). Here are the highlights, with timestamps in seconds: [3851435] NMI

Which came first, hard kernel lockup or SATA errors?

I'm trying to untangle a series of problems that suddenly occurred on a dual-socket Xeon server system that had been running a bunch of KVM workloads just fine for over 6 weeks (4.4.52-grsec kernel, Debian-derived userspace). Here are the highlights, with timestamps in seconds: [3851435] NMI

[PATCH] thermal: intel_pch_thermal: Read large temp values correctly

On all supported platforms, the TS Reading (TSR) field in the Temperature (TEMP) register is 9 bits wide. Values above 0x100 (78 degrees C) are plausible, so don't mask out the topmost bit. And the register itself is 16 bits wide, so use readw() rather than readl(). Signed-off-by: Ed Swierk <e

[PATCH] thermal: intel_pch_thermal: Read large temp values correctly

On all supported platforms, the TS Reading (TSR) field in the Temperature (TEMP) register is 9 bits wide. Values above 0x100 (78 degrees C) are plausible, so don't mask out the topmost bit. And the register itself is 16 bits wide, so use readw() rather than readl(). Signed-off-by: Ed Swierk

[PATCH] thermal: intel_pch_thermal: Fix enable check on Broadwell-DE

to configure it, and the dynamic shutdown state should not prevent the driver from loading. The ETS flag itself indicates whether the thermal sensor is enabled, so use it instead of the TSDSS flag on all hardware platforms. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> --- drivers/t

[PATCH] thermal: intel_pch_thermal: Fix enable check on Broadwell-DE

to configure it, and the dynamic shutdown state should not prevent the driver from loading. The ETS flag itself indicates whether the thermal sensor is enabled, so use it instead of the TSDSS flag on all hardware platforms. Signed-off-by: Ed Swierk --- drivers/thermal/intel_pch_thermal.c | 4 ++-- 1 file

Disable all network protocols on an interface?

I have a Linux kernel 4.4 system hosting a number of kvm VMs. Physical interface eth0 connects to an 802.1Q trunk port on an external switch. Each VM has a virtual interface (e1000 or virtio-net) connected to the physical NIC through a macvtap interface and a VLAN interface; traffic between the

Disable all network protocols on an interface?

I have a Linux kernel 4.4 system hosting a number of kvm VMs. Physical interface eth0 connects to an 802.1Q trunk port on an external switch. Each VM has a virtual interface (e1000 or virtio-net) connected to the physical NIC through a macvtap interface and a VLAN interface; traffic between the

Re: [PATCH v2 00/11] staging: octeon: multi rx group (queue) support

On 8/31/16 13:57, Aaro Koskinen wrote: > This series implements multiple RX group support that should improve > the networking performance on multi-core OCTEONs. Basically we register > IRQ and NAPI for each group, and ask the HW to select the group for > the incoming packets based on hash. > >

Re: [PATCH v2 00/11] staging: octeon: multi rx group (queue) support

On 8/31/16 13:57, Aaro Koskinen wrote: > This series implements multiple RX group support that should improve > the networking performance on multi-core OCTEONs. Basically we register > IRQ and NAPI for each group, and ask the HW to select the group for > the incoming packets based on hash. > >

Re: [PATCH 0/9] staging: octeon: multi rx group (queue) support

On 8/31/16 14:20, Aaro Koskinen wrote: > On Wed, Aug 31, 2016 at 09:20:07AM -0700, Ed Swierk wrote: >> Here's my workaround: > > [...] > >> -static int cvm_oct_poll(struct oct_rx_group *rx_group, int budget) >> +static int cvm_oct_poll(int group, int budget) >&g

Re: [PATCH 0/9] staging: octeon: multi rx group (queue) support

On 8/31/16 14:20, Aaro Koskinen wrote: > On Wed, Aug 31, 2016 at 09:20:07AM -0700, Ed Swierk wrote: >> Here's my workaround: > > [...] > >> -static int cvm_oct_poll(struct oct_rx_group *rx_group, int budget) >> +static int cvm_oct_poll(int group, int budget) >&g

Re: [PATCH 0/9] staging: octeon: multi rx group (queue) support

Aaro Koskinen wrote: > Oops, looks like I tested without CONFIG_NET_POLL_CONTROLLER enabled > and that seems to be broken. Sorry. I'm not using CONFIG_NET_POLL_CONTROLLER either; the problem is in the normal cvm_oct_napi_poll() path. Here's my workaround: ---

Re: [PATCH 0/9] staging: octeon: multi rx group (queue) support

Aaro Koskinen wrote: > Oops, looks like I tested without CONFIG_NET_POLL_CONTROLLER enabled > and that seems to be broken. Sorry. I'm not using CONFIG_NET_POLL_CONTROLLER either; the problem is in the normal cvm_oct_napi_poll() path. Here's my workaround: ---

Re: [PATCH 0/9] staging: octeon: multi rx group (queue) support

Hi Aaro, On Tue, Aug 30, 2016 at 11:47 AM, Aaro Koskinen wrote: > This series implements multiple RX group support that should improve > the networking performance on multi-core OCTEONs. Basically we register > IRQ and NAPI for each group, and ask the HW to select the group

Re: [PATCH 0/9] staging: octeon: multi rx group (queue) support

Hi Aaro, On Tue, Aug 30, 2016 at 11:47 AM, Aaro Koskinen wrote: > This series implements multiple RX group support that should improve > the networking performance on multi-core OCTEONs. Basically we register > IRQ and NAPI for each group, and ask the HW to select the group for > the incoming

Re: [PATCH] xenbus: don't look up transaction IDs for ordinary writes

On Tue, Aug 16, 2016 at 3:07 AM, Juergen Gross wrote: > On 15/08/16 17:02, Jan Beulich wrote: >> This should really only be done for XS_TRANSACTION_END messages, or >> else at least some of the xenstore-* tools don't work anymore. >> >> Fixes: 0beef634b8 ("xenbus: don't BUG() on

Re: [PATCH] xenbus: don't look up transaction IDs for ordinary writes

On Tue, Aug 16, 2016 at 3:07 AM, Juergen Gross wrote: > On 15/08/16 17:02, Jan Beulich wrote: >> This should really only be done for XS_TRANSACTION_END messages, or >> else at least some of the xenstore-* tools don't work anymore. >> >> Fixes: 0beef634b8 ("xenbus: don't BUG() on user mode induced

Re: [PATCH v9 0/5] tpm: Command duration logging and chip-specific override

On Wed, Jul 13, 2016 at 10:36 AM, Jason Gunthorpe wrote: > I think your bios is broken? The BIOS is broken in many ways. I already have to pass memmap=256M$0x8000, otherwise PCIe extended config space (MMCONFIG) is inaccessible. Also I found

Re: [PATCH v9 0/5] tpm: Command duration logging and chip-specific override

On Wed, Jul 13, 2016 at 10:36 AM, Jason Gunthorpe wrote: > I think your bios is broken? The BIOS is broken in many ways. I already have to pass memmap=256M$0x8000, otherwise PCIe extended config space (MMCONFIG) is inaccessible. Also I found memmap=0x7000$0x7a7d works around "APEI: Can

Re: [PATCH v9 0/5] tpm: Command duration logging and chip-specific override

On Wed, Jul 13, 2016 at 9:19 AM, Ed Swierk <eswi...@skyportsystems.com> wrote: > v9: Include command duration in existing error messages rather than > logging an extra debug message. Rebase onto Jarkko's tree. Incidentally, with Jarkko's tree the tpm_tis module refuses t

[PATCH v9 2/5] tpm: Add optional logging of TPM command durations

red with DYNAMIC_DEBUG=y. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> --- drivers/char/tpm/tpm-interface.c | 19 +-- 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/drivers/char/tpm/tp

Re: [PATCH v9 0/5] tpm: Command duration logging and chip-specific override

On Wed, Jul 13, 2016 at 9:19 AM, Ed Swierk wrote: > v9: Include command duration in existing error messages rather than > logging an extra debug message. Rebase onto Jarkko's tree. Incidentally, with Jarkko's tree the tpm_tis module refuses to initialize (with or without force=1): tpm_tis

[PATCH v9 2/5] tpm: Add optional logging of TPM command durations

red with DYNAMIC_DEBUG=y. Signed-off-by: Ed Swierk Reviewed-by: Jarkko Sakkinen --- drivers/char/tpm/tpm-interface.c | 19 +-- 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index 5e3c1b6..a4beb53 100

[PATCH v9 3/5] tpm: Clean up reading of timeout and duration capabilities

Call tpm_getcap() from tpm_get_timeouts() to eliminate redundant code. Return all errors to the caller rather than swallowing them (e.g. when tpm_transmit_cmd() returns nonzero). Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> --- drivers/char/tpm/tpm-interface.

[PATCH v9 3/5] tpm: Clean up reading of timeout and duration capabilities

Call tpm_getcap() from tpm_get_timeouts() to eliminate redundant code. Return all errors to the caller rather than swallowing them (e.g. when tpm_transmit_cmd() returns nonzero). Signed-off-by: Ed Swierk --- drivers/char/tpm/tpm-interface.c | 74 +++- 1 file

[PATCH v9 4/5] tpm: Allow TPM chip drivers to override reported command durations

-by: Ed Swierk <eswi...@skyportsystems.com> --- drivers/char/tpm/tpm-interface.c | 148 ++- drivers/char/tpm/tpm_tis_core.c | 32 +++-- include/linux/tpm.h | 3 +- 3 files changed, 94 insertions(+), 89 deletions(-) diff --git a/drivers/ch

[PATCH v9 4/5] tpm: Allow TPM chip drivers to override reported command durations

-by: Ed Swierk --- drivers/char/tpm/tpm-interface.c | 148 ++- drivers/char/tpm/tpm_tis_core.c | 32 +++-- include/linux/tpm.h | 3 +- 3 files changed, 94 insertions(+), 89 deletions(-) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers

[PATCH v9 0/5] tpm: Command duration logging and chip-specific override

-specific override of command durations as well as protocol timeouts - overrides ST19NP18 TPM command duration to avoid lockups Ed Swierk (5): tpm_tis: Improve reporting of IO errors tpm: Add optional logging of TPM command durations tpm: Clean up reading of timeout and duration capabilities

[PATCH v9 0/5] tpm: Command duration logging and chip-specific override

-specific override of command durations as well as protocol timeouts - overrides ST19NP18 TPM command duration to avoid lockups Ed Swierk (5): tpm_tis: Improve reporting of IO errors tpm: Add optional logging of TPM command durations tpm: Clean up reading of timeout and duration capabilities

[PATCH v9 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

hether any commands are immune to being blocked by this process. So it seems safest to ignore the chip's reported command durations, and use a value much higher than any observed duration, like 180 sec (which is the duration this chip reports for "long" commands). Signed-off-by: Ed Swierk <esw

[PATCH v9 1/5] tpm_tis: Improve reporting of IO errors

Mysterious TPM behavior can be difficult to track down through all the layers of software. Add error messages for conditions that should never happen. Also include the manufacturer ID along with other chip data printed during init. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Re

[PATCH v9 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

hether any commands are immune to being blocked by this process. So it seems safest to ignore the chip's reported command durations, and use a value much higher than any observed duration, like 180 sec (which is the duration this chip reports for "long" commands). Signed-off-by: Ed Swierk -

[PATCH v9 1/5] tpm_tis: Improve reporting of IO errors

Mysterious TPM behavior can be difficult to track down through all the layers of software. Add error messages for conditions that should never happen. Also include the manufacturer ID along with other chip data printed during init. Signed-off-by: Ed Swierk Reviewed-by: Jarkko Sakkinen

[PATCH v8 3/5] tpm: Clean up reading of timeout and duration capabilities

Call tpm_getcap() from tpm_get_timeouts() to eliminate redundant code. Return all errors to the caller rather than swallowing them (e.g. when tpm_transmit_cmd() returns nonzero). Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> --- drivers/char/tpm/tpm-interface.

[PATCH v8 3/5] tpm: Clean up reading of timeout and duration capabilities

Call tpm_getcap() from tpm_get_timeouts() to eliminate redundant code. Return all errors to the caller rather than swallowing them (e.g. when tpm_transmit_cmd() returns nonzero). Signed-off-by: Ed Swierk --- drivers/char/tpm/tpm-interface.c | 74 +++- 1 file

[PATCH v8 2/5] tpm: Add optional logging of TPM command durations

red with DYNAMIC_DEBUG=y. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> --- drivers/char/tpm/tpm-interface.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/char/tpm/tp

[PATCH v8 2/5] tpm: Add optional logging of TPM command durations

red with DYNAMIC_DEBUG=y. Signed-off-by: Ed Swierk Reviewed-by: Jarkko Sakkinen --- drivers/char/tpm/tpm-interface.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index c50637d..cc1e5bc 100

[PATCH v8 4/5] tpm: Allow TPM chip drivers to override reported command durations

-by: Ed Swierk <eswi...@skyportsystems.com> --- drivers/char/tpm/tpm-interface.c | 143 +-- drivers/char/tpm/tpm_tis.c | 35 +++--- include/linux/tpm.h | 3 +- 3 files changed, 88 insertions(+), 93 deletions(-) diff --git a/drivers/ch

[PATCH v8 0/5] tpm: Command duration logging and chip-specific override

both timeouts and durations via a single callback. This series - improves TPM command error reporting - adds optional logging of TPM command durations - allows chip-specific override of command durations as well as protocol timeouts - overrides ST19NP18 TPM command duration to avoid lockups Ed

[PATCH v8 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

hether any commands are immune to being blocked by this process. So it seems safest to ignore the chip's reported command durations, and use a value much higher than any observed duration, like 180 sec (which is the duration this chip reports for "long" commands). Signed-off-by: Ed Swierk <esw

[PATCH v8 4/5] tpm: Allow TPM chip drivers to override reported command durations

-by: Ed Swierk --- drivers/char/tpm/tpm-interface.c | 143 +-- drivers/char/tpm/tpm_tis.c | 35 +++--- include/linux/tpm.h | 3 +- 3 files changed, 88 insertions(+), 93 deletions(-) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers

[PATCH v8 0/5] tpm: Command duration logging and chip-specific override

both timeouts and durations via a single callback. This series - improves TPM command error reporting - adds optional logging of TPM command durations - allows chip-specific override of command durations as well as protocol timeouts - overrides ST19NP18 TPM command duration to avoid lockups Ed

[PATCH v8 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

hether any commands are immune to being blocked by this process. So it seems safest to ignore the chip's reported command durations, and use a value much higher than any observed duration, like 180 sec (which is the duration this chip reports for "long" commands). Signed-off-by: Ed Swierk -

[PATCH v8 1/5] tpm_tis: Improve reporting of IO errors

Mysterious TPM behavior can be difficult to track down through all the layers of software. Add error messages for conditions that should never happen. Also include the manufacturer ID along with other chip data printed during init. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Re

[PATCH v8 1/5] tpm_tis: Improve reporting of IO errors

Mysterious TPM behavior can be difficult to track down through all the layers of software. Add error messages for conditions that should never happen. Also include the manufacturer ID along with other chip data printed during init. Signed-off-by: Ed Swierk Reviewed-by: Jarkko Sakkinen

Re: [PATCH v7 3/5] tpm: Clean up reading of timeout and duration capabilities

On Mon, Jun 20, 2016 at 6:54 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: > --- a/drivers/char/tpm/tpm-interface.c > +++ b/drivers/char/tpm/tpm-interface.c > @@ -461,9 +461,19 @@ ssize_t tpm_getcap(struct device *dev, __be32 subcap_id

Re: [PATCH v7 3/5] tpm: Clean up reading of timeout and duration capabilities

On Mon, Jun 20, 2016 at 6:54 PM, Ed Swierk wrote: > --- a/drivers/char/tpm/tpm-interface.c > +++ b/drivers/char/tpm/tpm-interface.c > @@ -461,9 +461,19 @@ ssize_t tpm_getcap(struct device *dev, __be32 subcap_id, > cap_t *cap, > tpm_cmd.params.getcap_in.subcap_size

[PATCH v7 3/5] tpm: Clean up reading of timeout and duration capabilities

Call tpm_getcap() from tpm_get_timeouts() to eliminate redundant code. Return all errors to the caller rather than swallowing them (e.g. when tpm_transmit_cmd() returns nonzero). Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> --- drivers/char/tpm/tpm-interface.

[PATCH v7 3/5] tpm: Clean up reading of timeout and duration capabilities

Call tpm_getcap() from tpm_get_timeouts() to eliminate redundant code. Return all errors to the caller rather than swallowing them (e.g. when tpm_transmit_cmd() returns nonzero). Signed-off-by: Ed Swierk --- drivers/char/tpm/tpm-interface.c | 74 +++- 1 file

[PATCH v7 1/5] tpm_tis: Improve reporting of IO errors

Mysterious TPM behavior can be difficult to track down through all the layers of software. Add error messages for conditions that should never happen. Also include the manufacturer ID along with other chip data printed during init. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Re

[PATCH v7 1/5] tpm_tis: Improve reporting of IO errors

Mysterious TPM behavior can be difficult to track down through all the layers of software. Add error messages for conditions that should never happen. Also include the manufacturer ID along with other chip data printed during init. Signed-off-by: Ed Swierk Reviewed-by: Jarkko Sakkinen

[PATCH v7 0/5] tpm: Command duration logging and chip-specific override

a single callback. This series - improves TPM command error reporting - adds optional logging of TPM command durations - allows chip-specific override of command durations as well as protocol timeouts - overrides ST19NP18 TPM command duration to avoid lockups Ed Swierk (5): tpm_tis: Improve

[PATCH v7 4/5] tpm: Allow TPM chip drivers to override reported command durations

-by: Ed Swierk <eswi...@skyportsystems.com> --- drivers/char/tpm/tpm-interface.c | 143 +-- drivers/char/tpm/tpm_tis.c | 35 +++--- include/linux/tpm.h | 3 +- 3 files changed, 88 insertions(+), 93 deletions(-) diff --git a/drivers/ch

[PATCH v7 0/5] tpm: Command duration logging and chip-specific override

a single callback. This series - improves TPM command error reporting - adds optional logging of TPM command durations - allows chip-specific override of command durations as well as protocol timeouts - overrides ST19NP18 TPM command duration to avoid lockups Ed Swierk (5): tpm_tis: Improve

[PATCH v7 4/5] tpm: Allow TPM chip drivers to override reported command durations

-by: Ed Swierk --- drivers/char/tpm/tpm-interface.c | 143 +-- drivers/char/tpm/tpm_tis.c | 35 +++--- include/linux/tpm.h | 3 +- 3 files changed, 88 insertions(+), 93 deletions(-) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers

[PATCH v7 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

hether any commands are immune to being blocked by this process. So it seems safest to ignore the chip's reported command durations, and use a value much higher than any observed duration, like 180 sec (which is the duration this chip reports for "long" commands). Signed-off-by: Ed Swierk <esw

[PATCH v7 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

hether any commands are immune to being blocked by this process. So it seems safest to ignore the chip's reported command durations, and use a value much higher than any observed duration, like 180 sec (which is the duration this chip reports for "long" commands). Signed-off-by: Ed Swierk -

[PATCH v7 2/5] tpm: Add optional logging of TPM command durations

red with DYNAMIC_DEBUG=y. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> --- drivers/char/tpm/tpm-interface.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/char/tpm/tp

[PATCH v7 2/5] tpm: Add optional logging of TPM command durations

red with DYNAMIC_DEBUG=y. Signed-off-by: Ed Swierk Reviewed-by: Jarkko Sakkinen --- drivers/char/tpm/tpm-interface.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index c50637d..cc1e5bc 100

[PATCH v6 2/5] tpm: Add optional logging of TPM command durations

red with DYNAMIC_DEBUG=y. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> --- drivers/char/tpm/tpm-interface.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/char/tpm/tp

[PATCH v6 2/5] tpm: Add optional logging of TPM command durations

red with DYNAMIC_DEBUG=y. Signed-off-by: Ed Swierk Reviewed-by: Jarkko Sakkinen --- drivers/char/tpm/tpm-interface.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index c50637d..cc1e5bc 100

[PATCH v6 3/5] tpm: Factor out reading of timeout and duration capabilities

Factor sending the TPM_GetCapability command and validating the result from tpm_get_timeouts() into a new function. Return all errors to the caller rather than swallowing them (e.g. when tpm_transmit_cmd() returns nonzero). Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> --- driver

[PATCH v6 4/5] tpm: Allow TPM chip drivers to override reported command durations

-by: Ed Swierk <eswi...@skyportsystems.com> --- drivers/char/tpm/tpm-interface.c | 139 +-- drivers/char/tpm/tpm_tis.c | 35 +++--- include/linux/tpm.h | 3 +- 3 files changed, 85 insertions(+), 92 deletions(-) diff --git a/drivers/ch

[PATCH v6 0/5] tpm: Command duration logging and chip-specific override

reporting - adds optional logging of TPM command durations - allows chip-specific override of command durations as well as protocol timeouts - overrides ST19NP18 TPM command duration to avoid lockups Ed Swierk (5): tpm_tis: Improve reporting of IO errors tpm: Add optional logging of TPM command

[PATCH v6 3/5] tpm: Factor out reading of timeout and duration capabilities

Factor sending the TPM_GetCapability command and validating the result from tpm_get_timeouts() into a new function. Return all errors to the caller rather than swallowing them (e.g. when tpm_transmit_cmd() returns nonzero). Signed-off-by: Ed Swierk --- drivers/char/tpm/tpm-interface.c | 96

[PATCH v6 4/5] tpm: Allow TPM chip drivers to override reported command durations

-by: Ed Swierk --- drivers/char/tpm/tpm-interface.c | 139 +-- drivers/char/tpm/tpm_tis.c | 35 +++--- include/linux/tpm.h | 3 +- 3 files changed, 85 insertions(+), 92 deletions(-) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers

[PATCH v6 0/5] tpm: Command duration logging and chip-specific override

reporting - adds optional logging of TPM command durations - allows chip-specific override of command durations as well as protocol timeouts - overrides ST19NP18 TPM command duration to avoid lockups Ed Swierk (5): tpm_tis: Improve reporting of IO errors tpm: Add optional logging of TPM command

[PATCH v6 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

hether any commands are immune to being blocked by this process. So it seems safest to ignore the chip's reported command durations, and use a value much higher than any observed duration, like 180 sec (which is the duration this chip reports for "long" commands). Signed-off-by: Ed Swierk <esw

[PATCH v6 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

hether any commands are immune to being blocked by this process. So it seems safest to ignore the chip's reported command durations, and use a value much higher than any observed duration, like 180 sec (which is the duration this chip reports for "long" commands). Signed-off-by: Ed Swierk -

[PATCH v6 1/5] tpm_tis: Improve reporting of IO errors

Mysterious TPM behavior can be difficult to track down through all the layers of software. Add error messages for conditions that should never happen. Also include the manufacturer ID along with other chip data printed during init. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Re

[PATCH v6 1/5] tpm_tis: Improve reporting of IO errors

Mysterious TPM behavior can be difficult to track down through all the layers of software. Add error messages for conditions that should never happen. Also include the manufacturer ID along with other chip data printed during init. Signed-off-by: Ed Swierk Reviewed-by: Jarkko Sakkinen

Re: [PATCH v5 3/4] tpm: Allow TPM chip drivers to override reported command durations

On Fri, Jun 10, 2016 at 12:42 PM, Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> wrote: > On Fri, Jun 10, 2016 at 10:34:15AM -0700, Ed Swierk wrote: >> On Fri, Jun 10, 2016 at 5:19 AM, Jarkko Sakkinen >> <jarkko.sakki...@linux.intel.com> wrote: >> > On Wed,

Re: [PATCH v5 3/4] tpm: Allow TPM chip drivers to override reported command durations

On Fri, Jun 10, 2016 at 12:42 PM, Jarkko Sakkinen wrote: > On Fri, Jun 10, 2016 at 10:34:15AM -0700, Ed Swierk wrote: >> On Fri, Jun 10, 2016 at 5:19 AM, Jarkko Sakkinen >> wrote: >> > On Wed, Jun 08, 2016 at 04:00:17PM -0700, Ed Swierk wrote: >> >> Some TPM

Re: [PATCH v5 3/4] tpm: Allow TPM chip drivers to override reported command durations

On Fri, Jun 10, 2016 at 5:19 AM, Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> wrote: > On Wed, Jun 08, 2016 at 04:00:17PM -0700, Ed Swierk wrote: >> Some TPM chips report bogus command durations in their capabilities, >> just as others report incorrect timeouts. Re

Re: [PATCH v5 3/4] tpm: Allow TPM chip drivers to override reported command durations

On Fri, Jun 10, 2016 at 5:19 AM, Jarkko Sakkinen wrote: > On Wed, Jun 08, 2016 at 04:00:17PM -0700, Ed Swierk wrote: >> Some TPM chips report bogus command durations in their capabilities, >> just as others report incorrect timeouts. Rework tpm_get_timeouts() >> to allow chi

[PATCH v5 4/4] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

hether any commands are immune to being blocked by this process. So it seems safest to ignore the chip's reported command durations, and use a value much higher than any observed duration, like 180 sec (which is the duration this chip reports for "long" commands). Signed-off-by: Ed Swierk <esw

[PATCH v5 1/4] tpm_tis: Improve reporting of IO errors

Mysterious TPM behavior can be difficult to track down through all the layers of software. Add error messages for conditions that should never happen. Also include the manufacturer ID along with other chip data printed during init. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Re

[PATCH v5 4/4] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

hether any commands are immune to being blocked by this process. So it seems safest to ignore the chip's reported command durations, and use a value much higher than any observed duration, like 180 sec (which is the duration this chip reports for "long" commands). Signed-off-by: Ed Swierk -

[PATCH v5 1/4] tpm_tis: Improve reporting of IO errors

Mysterious TPM behavior can be difficult to track down through all the layers of software. Add error messages for conditions that should never happen. Also include the manufacturer ID along with other chip data printed during init. Signed-off-by: Ed Swierk Reviewed-by: Jarkko Sakkinen

[PATCH v5 0/4] tpm: Command duration logging and chip-specific override

durations as well as protocol timeouts - overrides ST19NP18 TPM command duration to avoid lockups Ed Swierk (4): tpm_tis: Improve reporting of IO errors tpm: Add optional logging of TPM command durations tpm: Allow TPM chip drivers to override reported command durations tpm_tis: Increase

[PATCH v5 0/4] tpm: Command duration logging and chip-specific override

durations as well as protocol timeouts - overrides ST19NP18 TPM command duration to avoid lockups Ed Swierk (4): tpm_tis: Improve reporting of IO errors tpm: Add optional logging of TPM command durations tpm: Allow TPM chip drivers to override reported command durations tpm_tis: Increase

[PATCH v5 3/4] tpm: Allow TPM chip drivers to override reported command durations

-by: Ed Swierk <eswi...@skyportsystems.com> --- drivers/char/tpm/tpm-interface.c | 177 +-- drivers/char/tpm/tpm_tis.c | 35 ++-- include/linux/tpm.h | 3 +- 3 files changed, 106 insertions(+), 109 deletions(-) diff --git a/drivers/ch

[PATCH v5 2/4] tpm: Add optional logging of TPM command durations

red with DYNAMIC_DEBUG=y. Signed-off-by: Ed Swierk <eswi...@skyportsystems.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> --- drivers/char/tpm/tpm-interface.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/char/tpm/tp

[PATCH v5 2/4] tpm: Add optional logging of TPM command durations

red with DYNAMIC_DEBUG=y. Signed-off-by: Ed Swierk Reviewed-by: Jarkko Sakkinen --- drivers/char/tpm/tpm-interface.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index c50637d..cc1e5bc 100

[PATCH v5 3/4] tpm: Allow TPM chip drivers to override reported command durations

-by: Ed Swierk --- drivers/char/tpm/tpm-interface.c | 177 +-- drivers/char/tpm/tpm_tis.c | 35 ++-- include/linux/tpm.h | 3 +- 3 files changed, 106 insertions(+), 109 deletions(-) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers

  1   2   >