| Message ID | 5B8DA87D05A7694D9FA63FD143655C1B54395CD5@hasmsx108.ger.corp.intel.com |
|---|---|
| State | New |
| Headers | show |
On Thu, Feb 16, 2017 at 10:36:40PM +0000, Winkler, Tomas wrote: > This is a BIOS issue + kernel ACPI platform driver refusing to handle > overlapping memory space. The issue here is that the ACPI platform > driver is not created, however this should not prevent the tpm_crb > driver from working as it registers directly the ACPI device. For now > you can suppress the message by adding the device in forbidden_id_list > in drivers/acpi/acpi_platform.c > > > I'm already testing a fixed BIOS, not sure whether and when it will be > available for your particular device. Do you think we should go ahead with the patch I sent? Or should we tell users they need a BIOS update? Jason ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
On Fri, 2017-02-17 at 09:43 -0700, Jason Gunthorpe wrote: > On Thu, Feb 16, 2017 at 10:36:40PM +0000, Winkler, Tomas wrote: > > This is a BIOS issue + kernel ACPI platform driver refusing to > > handle > > overlapping memory space. The issue here is that the ACPI > > platform > > driver is not created, however this should not prevent the > > tpm_crb > > driver from working as it registers directly the ACPI device. > > For now > > you can suppress the message by adding the device in > > forbidden_id_list > > in drivers/acpi/acpi_platform.c > > > > > > I'm already testing a fixed BIOS, not sure whether and when it > > will be > > available for your particular device. > > Do you think we should go ahead with the patch I sent? Or should we > tell users they need a BIOS update? > > Jason I would rather review a patch with proper commit message than just pick from an email thread in all cases with a proper explanation what the patch does and why it is the right way to fix the issue. I got an email privately and identified it as the very same issue. It was in a NUC and the author said that he had updated the BIOS to the latest version. That supports the view of doing some kind of workaround to the driver, perhaps the way you did it. /Jarkko ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> I would rather review a patch with proper commit message than just pick > from an email thread in all cases with a proper explanation what the > patch does and why it is the right way to fix the issue. Of course, but I am waiting for Davide to say the approach even works .. Jason ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Hey, sorry fro the delayed reply. Jason's patch works. I had no doubt it would, because I tried a qnd patch with manually cropped sizes. I have cleaned it up a little bit, removing printks. Thanks again! D. > On 17 Feb 2017, at 7:01 pm, Jason Gunthorpe <jgunthorpe@obsidianresearch.com> wrote: > >> I would rather review a patch with proper commit message than just pick >> from an email thread in all cases with a proper explanation what the >> patch does and why it is the right way to fix the issue. > > Of course, but I am waiting for Davide to say the approach even works > .. > > Jason ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
I need few days to get into BIOS to understand how we got to here at the first place,
Can you please send me the dmidecode of the NUC (even privately) so I can understand what exactly issue we have. The fixed BIOS I'm testing now is for the Kaby Lake platform.
Davide if would fill a bug for that via intel support page so we can follow up on that.
Thanks
Tomas
From: Davide Guerri [mailto:davide.guerri@gmail.com]
Sent: Friday, February 17, 2017 23:15
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Sakkinen, Jarkko <jarkko.sakkinen@intel.com>; Winkler, Tomas <tomas.winkler@intel.com>; tpmdd-devel@lists.sourceforge.net
Subject: Re: [tpmdd-devel] Intel NUC and fTPM issue on 4.9.2
Hey,
sorry fro the delayed reply.
Jason's patch works. I had no doubt it would, because I tried a qnd patch with manually cropped sizes.
I have cleaned it up a little bit, removing printks.
Thanks again!
D.
On 17 Feb 2017, at 7:01 pm, Jason Gunthorpe <jgunthorpe@obsidianresearch.com<mailto:jgunthorpe@obsidianresearch.com>> wrote:
I would rather review a patch with proper commit message than just pick
from an email thread in all cases with a proper explanation what the
patch does and why it is the right way to fix the issue.
Of course, but I am waiting for Davide to say the approach even works
..
Jason
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
On Sun, Feb 19, 2017 at 10:28:08PM +0000, Winkler, Tomas wrote: > I need few days to get into BIOS to understand how we got to here at the > first place, > > Can you please send me the dmidecode of the NUC (even privately) so I can > understand what exactly issue we have. The fixed BIOS I’m testing now is > for the Kaby Lake platform. > > Davide if would fill a bug for that via intel support page so we can > follow up on that. > > > > Thanks > > Tomas I don't want to be impolite but can you please stop constantly sending HTML messages to the list and top-posting. This has now happend multiple times. Thank you. /Jarkko > > > > From: Davide Guerri [mailto:davide.guerri@gmail.com] > Sent: Friday, February 17, 2017 23:15 > To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> > Cc: Sakkinen, Jarkko <jarkko.sakkinen@intel.com>; Winkler, Tomas > <tomas.winkler@intel.com>; tpmdd-devel@lists.sourceforge.net > Subject: Re: [tpmdd-devel] Intel NUC and fTPM issue on 4.9.2 > > > > Hey, > > sorry fro the delayed reply. > > > > Jason's patch works. I had no doubt it would, because I tried a qnd patch > with manually cropped sizes. > > I have cleaned it up a little bit, removing printks. > > > > Thanks again! > > > > D. > > > > > > On 17 Feb 2017, at 7:01 pm, Jason Gunthorpe > <jgunthorpe@obsidianresearch.com> wrote: > > > > I would rather review a patch with proper commit message than just > pick > from an email thread in all cases with a proper explanation what the > patch does and why it is the right way to fix the issue. > > Of course, but I am waiting for Davide to say the approach even works > .. > > Jason > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > tpmdd-devel mailing list > tpmdd-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tpmdd-devel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
On Fri, Feb 17, 2017 at 12:01:25PM -0700, Jason Gunthorpe wrote: > > I would rather review a patch with proper commit message than just pick > > from an email thread in all cases with a proper explanation what the > > patch does and why it is the right way to fix the issue. > > Of course, but I am waiting for Davide to say the approach even works > .. > > Jason I'm not sure what would be a good function name but maybe something that would state that this is not status quo but workaround for a bug. Since I do not have any better suggestion keep the current name if nothing comes up. Probably a dev_err message would make sense here to state in klog that something is wrong in the BIOS. Since there are multiple people complaining about the issue I will take this workaround even if the BIOS is fixed. /Jarkko ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> -----Original Message----- > From: Jarkko Sakkinen [mailto:jarkko.sakkinen@linux.intel.com] > Sent: Monday, February 20, 2017 12:48 > To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> > Cc: Sakkinen, Jarkko <jarkko.sakkinen@intel.com>; tpmdd- > devel@lists.sourceforge.net; davide.guerri@gmail.com > Subject: Re: [tpmdd-devel] Intel NUC and fTPM issue on 4.9.2 > > On Fri, Feb 17, 2017 at 12:01:25PM -0700, Jason Gunthorpe wrote: > > > I would rather review a patch with proper commit message than just > > > pick from an email thread in all cases with a proper explanation > > > what the patch does and why it is the right way to fix the issue. > > > > Of course, but I am waiting for Davide to say the approach even works > > .. > > > > Jason > > I'm not sure what would be a good function name but maybe something that > would state that this is not status quo but workaround for a bug. Since I do not > have any better suggestion keep the current name if nothing comes up. > > Probably a dev_err message would make sense here to state in klog that > something is wrong in the BIOS. > > Since there are multiple people complaining about the issue I will take this > workaround even if the BIOS is fixed. > > /Jarkko There is finally a BIOS fix https://downloadcenter.intel.com/download/26698/NUCs-BIOS-Update-KYSKLi70-86A- 0045 and newer Thanks Tomas ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c index a7c870af916c3d..acc54a03d6025d 100644 --- a/drivers/char/tpm/tpm_crb.c +++ b/drivers/char/tpm/tpm_crb.c @@ -233,6 +233,8 @@ static void __iomem *crb_map_res(struct device *dev, struct crb_priv *priv, .flags = IORESOURCE_MEM, }; + printk("map request is is %pr\n",&new_res); + /* Detect a 64 bit address on a 32 bit system */ if (start != new_res.start) return (void __iomem *) ERR_PTR(-EINVAL); @@ -267,6 +269,8 @@ static int crb_map_io(struct acpi_device *device, struct crb_priv *priv, return -EINVAL; } + printk("ACPI resource is %pr\n",&io_res); + priv->iobase = devm_ioremap_resource(dev, &io_res); if (IS_ERR(priv->iobase)) return PTR_ERR(priv->iobase);