On Thu, Aug 17, 2017 at 11:17:32AM -0600, Jason Gunthorpe wrote:
> On Thu, Aug 17, 2017 at 12:38:07PM +0200, Sebastian Andrzej Siewior wrote:
>
> > > I worry a bit about "appears to fix". It seems odd that the TPM device
> > > driver would be the first code to uncover this. Can anyone confirm
On Thu, Aug 17, 2017 at 11:17:32AM -0600, Jason Gunthorpe wrote:
> On Thu, Aug 17, 2017 at 12:38:07PM +0200, Sebastian Andrzej Siewior wrote:
>
> > > I worry a bit about "appears to fix". It seems odd that the TPM device
> > > driver would be the first code to uncover this. Can anyone confirm
Neither wmb() nor mb() have any effect when substituted for
ioread8(iobase + TPM_ACCESS(0)) in tpm_tis_flush(). I still see 300 -
400 us spikes in cyclictest invoking my TPM chip's RNG.
-- Haris
On 08/17/2017 12:17 PM, Jason Gunthorpe wrote:
On Thu, Aug 17, 2017 at 12:38:07PM +0200,
Neither wmb() nor mb() have any effect when substituted for
ioread8(iobase + TPM_ACCESS(0)) in tpm_tis_flush(). I still see 300 -
400 us spikes in cyclictest invoking my TPM chip's RNG.
-- Haris
On 08/17/2017 12:17 PM, Jason Gunthorpe wrote:
On Thu, Aug 17, 2017 at 12:38:07PM +0200,
On Thu, Aug 17, 2017 at 12:38:07PM +0200, Sebastian Andrzej Siewior wrote:
> > I worry a bit about "appears to fix". It seems odd that the TPM device
> > driver would be the first code to uncover this. Can anyone confirm that the
> > chipset does indeed have this bug?
>
> What Haris says makes
On Thu, Aug 17, 2017 at 12:38:07PM +0200, Sebastian Andrzej Siewior wrote:
> > I worry a bit about "appears to fix". It seems odd that the TPM device
> > driver would be the first code to uncover this. Can anyone confirm that the
> > chipset does indeed have this bug?
>
> What Haris says makes
On 2017-08-16 17:15:55 [-0400], Ken Goldman wrote:
> On 8/15/2017 4:13 PM, Haris Okanovic wrote:
> > ioread8() operations to TPM MMIO addresses can stall the cpu when
> > immediately following a sequence of iowrite*()'s to the same region.
> >
> > For example, cyclitest measures ~400us latency
On 2017-08-16 17:15:55 [-0400], Ken Goldman wrote:
> On 8/15/2017 4:13 PM, Haris Okanovic wrote:
> > ioread8() operations to TPM MMIO addresses can stall the cpu when
> > immediately following a sequence of iowrite*()'s to the same region.
> >
> > For example, cyclitest measures ~400us latency
On Wednesday 16 August 2017 17:15:55, Ken Goldman wrote:
> On 8/15/2017 4:13 PM, Haris Okanovic wrote:
> > ioread8() operations to TPM MMIO addresses can stall the cpu when
> > immediately following a sequence of iowrite*()'s to the same region.
> >
> > For example, cyclitest measures ~400us
On Wednesday 16 August 2017 17:15:55, Ken Goldman wrote:
> On 8/15/2017 4:13 PM, Haris Okanovic wrote:
> > ioread8() operations to TPM MMIO addresses can stall the cpu when
> > immediately following a sequence of iowrite*()'s to the same region.
> >
> > For example, cyclitest measures ~400us
On 8/15/2017 4:13 PM, Haris Okanovic wrote:
ioread8() operations to TPM MMIO addresses can stall the cpu when
immediately following a sequence of iowrite*()'s to the same region.
For example, cyclitest measures ~400us latency spikes when a non-RT
usermode application communicates with an
On 8/15/2017 4:13 PM, Haris Okanovic wrote:
ioread8() operations to TPM MMIO addresses can stall the cpu when
immediately following a sequence of iowrite*()'s to the same region.
For example, cyclitest measures ~400us latency spikes when a non-RT
usermode application communicates with an
ioread8() operations to TPM MMIO addresses can stall the cpu when
immediately following a sequence of iowrite*()'s to the same region.
For example, cyclitest measures ~400us latency spikes when a non-RT
usermode application communicates with an SPI-based TPM chip (Intel Atom
E3940 system,
ioread8() operations to TPM MMIO addresses can stall the cpu when
immediately following a sequence of iowrite*()'s to the same region.
For example, cyclitest measures ~400us latency spikes when a non-RT
usermode application communicates with an SPI-based TPM chip (Intel Atom
E3940 system,
14 matches
Mail list logo