On Tue, Nov 22, 2016 at 08:07:42AM +0200, Jarkko Sakkinen wrote:
> On Sat, Nov 19, 2016 at 11:32:55AM -0700, Jason Gunthorpe wrote:
> > On Thu, Nov 17, 2016 at 06:15:20PM -0500, Stefan Berger wrote:
> >
> > > >>Further, I had the impression that the error unwinding following
> > > >>-ENODEV has
>
On Sat, Nov 19, 2016 at 11:32:55AM -0700, Jason Gunthorpe wrote:
> On Thu, Nov 17, 2016 at 06:15:20PM -0500, Stefan Berger wrote:
>
> > >>Further, I had the impression that the error unwinding following -ENODEV
> > >>has
> > >>an issue related to sysfs.
> > >I don't follow this comment..
> >
> >
On Fri, Nov 18, 2016 at 11:58:08AM -0500, Stefan Berger wrote:
> reason is just the acpi_os_map_iomem() call. Without calling the
> acpi_os_unmap_iomem() later on, which I assume should be allowed, the driver
> will crash when the device terminates.
The oops looks like unbalacned map/unmap, can y
On 11/19/2016 01:32 PM, Jason Gunthorpe wrote:
> On Thu, Nov 17, 2016 at 06:15:20PM -0500, Stefan Berger wrote:
>
Further, I had the impression that the error unwinding following -ENODEV
has
an issue related to sysfs.
>>> I don't follow this comment..
>> I have encountered this erro
On Thu, Nov 17, 2016 at 06:15:20PM -0500, Stefan Berger wrote:
> >>Further, I had the impression that the error unwinding following -ENODEV has
> >>an issue related to sysfs.
> >I don't follow this comment..
>
> I have encountered this error here, which gets masked when applying the
> previously
On 11/18/2016 09:15 AM, Stefan Berger wrote:
> On 11/18/2016 09:11 AM, Stefan Berger wrote:
>> On 11/17/2016 03:37 PM, Jarkko Sakkinen wrote:
>>> On Thu, Nov 17, 2016 at 07:35:05AM -0500, Stefan Berger wrote:
On 11/16/2016 03:07 PM, Jason Gunthorpe wrote:
> On Wed, Nov 16, 2016 at 12:07:23
On 11/18/2016 09:11 AM, Stefan Berger wrote:
> On 11/17/2016 03:37 PM, Jarkko Sakkinen wrote:
>> On Thu, Nov 17, 2016 at 07:35:05AM -0500, Stefan Berger wrote:
>>> On 11/16/2016 03:07 PM, Jason Gunthorpe wrote:
On Wed, Nov 16, 2016 at 12:07:23PM -0500, Stefan Berger wrote:
> The culprit se
On 11/17/2016 03:37 PM, Jarkko Sakkinen wrote:
> On Thu, Nov 17, 2016 at 07:35:05AM -0500, Stefan Berger wrote:
>> On 11/16/2016 03:07 PM, Jason Gunthorpe wrote:
>>> On Wed, Nov 16, 2016 at 12:07:23PM -0500, Stefan Berger wrote:
The culprit seems to be 'tpm: fix the missing .owner in
tpm_
On 11/18/2016 12:03 AM, Jason Gunthorpe wrote:
> On Thu, Nov 17, 2016 at 01:25:54PM -0500, Stefan Berger wrote:
>>
>> In the case of x86, tpm_read_log_of() is a stub return -ENODEV, which in
>> turn fails the whole device:
>
> Somehow this got screwed up during the lengthy review. ENODEV is the
>
On Thu, Nov 17, 2016 at 06:15:20PM -0500, Stefan Berger wrote:
> On 11/17/2016 01:33 PM, Jason Gunthorpe wrote:
> > On Thu, Nov 17, 2016 at 01:25:54PM -0500, Stefan Berger wrote:
> > > In the case of x86, tpm_read_log_of() is a stub return -ENODEV, which in
> > > turn fails the whole device:
> > So
On 11/17/2016 01:33 PM, Jason Gunthorpe wrote:
> On Thu, Nov 17, 2016 at 01:25:54PM -0500, Stefan Berger wrote:
>> In the case of x86, tpm_read_log_of() is a stub return -ENODEV, which in
>> turn fails the whole device:
> Somehow this got screwed up during the lengthy review. ENODEV is the
> right
On Thu, Nov 17, 2016 at 07:35:05AM -0500, Stefan Berger wrote:
> On 11/16/2016 03:07 PM, Jason Gunthorpe wrote:
> > On Wed, Nov 16, 2016 at 12:07:23PM -0500, Stefan Berger wrote:
> > > The culprit seems to be 'tpm: fix the missing .owner in
> > > tpm_bios_measurements_ops'
> > That is unlikely, it
On Wed, Nov 16, 2016 at 01:07:59PM -0700, Jason Gunthorpe wrote:
> On Wed, Nov 16, 2016 at 12:07:23PM -0500, Stefan Berger wrote:
> > The culprit seems to be 'tpm: fix the missing .owner in
> > tpm_bios_measurements_ops'
>
> That is unlikely, it is probably the patch before which calls read_log
>
On Thu, Nov 17, 2016 at 01:25:54PM -0500, Stefan Berger wrote:
>
> In the case of x86, tpm_read_log_of() is a stub return -ENODEV, which in
> turn fails the whole device:
Somehow this got screwed up during the lengthy review. ENODEV is the
right return from the leaf routines but the tests in tpm_
On 11/17/2016 01:10 PM, Jason Gunthorpe wrote:
> 1;2802;0cOn Thu, Nov 17, 2016 at 07:35:05AM -0500, Stefan Berger wrote:
>> I ran the vtpm driver test suite (with -j32) a few times at that patch and
>> it didn't crash. It crashes severely with later patches applied. Here's the
>> current experiment
1;2802;0cOn Thu, Nov 17, 2016 at 07:35:05AM -0500, Stefan Berger wrote:
> I ran the vtpm driver test suite (with -j32) a few times at that patch and
> it didn't crash. It crashes severely with later patches applied. Here's the
> current experimental patch that fixes these problems:
I can't see how
On 11/16/2016 03:07 PM, Jason Gunthorpe wrote:
> On Wed, Nov 16, 2016 at 12:07:23PM -0500, Stefan Berger wrote:
>> The culprit seems to be 'tpm: fix the missing .owner in
>> tpm_bios_measurements_ops'
> That is unlikely, it is probably the patch before which calls read_log
> unconditionally now. Th
On Wed, Nov 16, 2016 at 12:07:23PM -0500, Stefan Berger wrote:
> The culprit seems to be 'tpm: fix the missing .owner in
> tpm_bios_measurements_ops'
That is unlikely, it is probably the patch before which calls read_log
unconditionally now. That suggests the crashing is a little random..
tpm_rea
On 11/16/2016 10:41 AM, Stefan Berger wrote:
> On 11/16/2016 10:37 AM, Jarkko Sakkinen wrote:
>> On Wed, Nov 16, 2016 at 09:24:05AM -0500, Stefan Berger wrote:
>>> The virtual TPM driver must not access the hosts's event log,
>>> otherwise we get crashes from that.
>>>
>>> Signed-off-by: Stefan Ber
On 11/16/2016 10:37 AM, Jarkko Sakkinen wrote:
> On Wed, Nov 16, 2016 at 09:24:05AM -0500, Stefan Berger wrote:
>> The virtual TPM driver must not access the hosts's event log,
>> otherwise we get crashes from that.
>>
>> Signed-off-by: Stefan Berger
> Can you give me a "Fixes" line (no need to se
On Wed, Nov 16, 2016 at 09:24:05AM -0500, Stefan Berger wrote:
> The virtual TPM driver must not access the hosts's event log,
> otherwise we get crashes from that.
>
> Signed-off-by: Stefan Berger
Can you give me a "Fixes" line (no need to send a new patch)?
> ---
> drivers/char/tpm/tpm_event
21 matches
Mail list logo