Re: [tpmdd-devel] [PATCH] TPM: Work around buggy TPMs that block during continue self test
Am Freitag, 25. Januar 2013, 21:25:38 schrieb Jason Gunthorpe: > > https://github.com/shpedoikal/linux.git tpmdd-01-22-13 > > Thanks Kent, I will try to test your branch next week, if I am able. > > Can you also grab > > https://github.com/jgunthorpe/linux/commit/98b2a198b43b41b0535200bf47516078 > 6398f114 > This one looks good to me. For this one please add my Reviewed-by: Peter Huewe Thanks, PeterH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] [PATCH] TPM: Work around buggy TPMs that block during continue self test
Am Freitag, 25. Januar 2013, 21:25:38 schrieb Jason Gunthorpe: https://github.com/shpedoikal/linux.git tpmdd-01-22-13 Thanks Kent, I will try to test your branch next week, if I am able. Can you also grab https://github.com/jgunthorpe/linux/commit/98b2a198b43b41b0535200bf47516078 6398f114 This one looks good to me. For this one please add my Reviewed-by: Peter Huewe peterhu...@gmx.de Thanks, PeterH -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] [PATCH] TPM: Work around buggy TPMs that block during continue self test
On Fri, Feb 01, 2013 at 04:38:42PM -0600, Kent Yoder wrote: > >> > https://github.com/shpedoikal/linux.git tpmdd-01-22-13 > >> > >> Thanks Kent, I will try to test your branch next week, if I am able. > >> > >> Can you also grab > >> > >> https://github.com/jgunthorpe/linux/commit/98b2a198b43b41b0535200bf475160786398f114 > > > > Thanks, I missed this, I'll start testing it. > > Ok, after yet another round of fixes to the stm i2c driver, I have a > staging tree. I'll submit this as-is next week unless something super > ground-breaking comes up. Great, I'll put this on my list.. I didn't receive your prior message, thank you for quoting it.. > >> https://github.com/jgunthorpe/linux/commit/9981e3e622bf702394982117134bed731ffd6f7e > > > > This one is a bit out of date atm, for instance the __dev* stuff is > > going away. The thing that most makes me hesitant though is the config > > if (X86 || OF). A hardware platform or a firmware type.. What platform > > should this actually target? Right on the __dev stuff.. Well the 'depends on' buisness is only due to the unconditional probing of TIS_MEM_BASE for a tpm, and then the autodetection of an IRQ number. That procedure is very much X86 only. My patch removes the unconditional probe when OF support is turned on, so it is safe to use on any platform only when OF is enabled. Yes it is really wonky, but unconditionally probing HW in a driver is wonky these days too.. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] [PATCH] TPM: Work around buggy TPMs that block during continue self test
On Mon, Jan 28, 2013 at 8:11 AM, Kent Yoder wrote: > On Fri, Jan 25, 2013 at 01:25:38PM -0700, Jason Gunthorpe wrote: >> On Tue, Jan 22, 2013 at 05:29:23PM -0600, Kent Yoder wrote: >> > Hi Jason, >> > >> > On Wed, Nov 21, 2012 at 3:15 PM, Jason Gunthorpe >> > wrote: >> > > We've been testing an alternative TPM for our embedded products and >> > > found random kernel boot failures due to time outs after the continue >> > > self test command. >> > > >> > > This was happening randomly, and has been *very* hard to track down, but >> > > it >> > > looks like with this chip there is some kind of race with the >> > > tpm_tis_status() >> > > check of TPM_STS_COMMAND_READY. If things get there 'too fast' then >> > > it sees the chip is ready, or tpm_tis_ready() works. Otherwise it takes >> > > somewhere over 400ms before the chip will return TPM_STS_COMMAND_READY. >> > > >> > > Adding some delay after tpm_continue_selftest() makes things reliably >> > > hit the failure path, otherwise it is a crapshot. >> > >> > I've staged this patch here, please test: >> > >> > https://github.com/shpedoikal/linux.git tpmdd-01-22-13 >> >> Thanks Kent, I will try to test your branch next week, if I am able. >> >> Can you also grab >> >> https://github.com/jgunthorpe/linux/commit/98b2a198b43b41b0535200bf475160786398f114 > > Thanks, I missed this, I'll start testing it. Ok, after yet another round of fixes to the stm i2c driver, I have a staging tree. I'll submit this as-is next week unless something super ground-breaking comes up. https://github.com/shpedoikal/linux.git tpmdd-01-31-13 Thanks, Kent >> And did you have any comments on: >> >> https://github.com/jgunthorpe/linux/commit/9981e3e622bf702394982117134bed731ffd6f7e > > This one is a bit out of date atm, for instance the __dev* stuff is > going away. The thing that most makes me hesitant though is the config > if (X86 || OF). A hardware platform or a firmware type.. What platform > should this actually target? > > Kent > >> Both were posted to the list a bit ago. >> >> Regards, >> -- >> Jason Gunthorpe (780)4406067x832 >> Chief Technology Officer, Obsidian Research Corp Edmonton, Canada >> >> -- >> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current >> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >> MVPs and experts. ON SALE this month only -- learn more at: >> http://p.sf.net/sfu/learnnow-d2d >> ___ >> tpmdd-devel mailing list >> tpmdd-de...@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/tpmdd-devel >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] [PATCH] TPM: Work around buggy TPMs that block during continue self test
On Mon, Jan 28, 2013 at 8:11 AM, Kent Yoder k...@linux.vnet.ibm.com wrote: On Fri, Jan 25, 2013 at 01:25:38PM -0700, Jason Gunthorpe wrote: On Tue, Jan 22, 2013 at 05:29:23PM -0600, Kent Yoder wrote: Hi Jason, On Wed, Nov 21, 2012 at 3:15 PM, Jason Gunthorpe jguntho...@obsidianresearch.com wrote: We've been testing an alternative TPM for our embedded products and found random kernel boot failures due to time outs after the continue self test command. This was happening randomly, and has been *very* hard to track down, but it looks like with this chip there is some kind of race with the tpm_tis_status() check of TPM_STS_COMMAND_READY. If things get there 'too fast' then it sees the chip is ready, or tpm_tis_ready() works. Otherwise it takes somewhere over 400ms before the chip will return TPM_STS_COMMAND_READY. Adding some delay after tpm_continue_selftest() makes things reliably hit the failure path, otherwise it is a crapshot. I've staged this patch here, please test: https://github.com/shpedoikal/linux.git tpmdd-01-22-13 Thanks Kent, I will try to test your branch next week, if I am able. Can you also grab https://github.com/jgunthorpe/linux/commit/98b2a198b43b41b0535200bf475160786398f114 Thanks, I missed this, I'll start testing it. Ok, after yet another round of fixes to the stm i2c driver, I have a staging tree. I'll submit this as-is next week unless something super ground-breaking comes up. https://github.com/shpedoikal/linux.git tpmdd-01-31-13 Thanks, Kent And did you have any comments on: https://github.com/jgunthorpe/linux/commit/9981e3e622bf702394982117134bed731ffd6f7e This one is a bit out of date atm, for instance the __dev* stuff is going away. The thing that most makes me hesitant though is the config if (X86 || OF). A hardware platform or a firmware type.. What platform should this actually target? Kent Both were posted to the list a bit ago. Regards, -- Jason Gunthorpe jguntho...@obsidianresearch.com(780)4406067x832 Chief Technology Officer, Obsidian Research Corp Edmonton, Canada -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ tpmdd-devel mailing list tpmdd-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] [PATCH] TPM: Work around buggy TPMs that block during continue self test
On Fri, Feb 01, 2013 at 04:38:42PM -0600, Kent Yoder wrote: https://github.com/shpedoikal/linux.git tpmdd-01-22-13 Thanks Kent, I will try to test your branch next week, if I am able. Can you also grab https://github.com/jgunthorpe/linux/commit/98b2a198b43b41b0535200bf475160786398f114 Thanks, I missed this, I'll start testing it. Ok, after yet another round of fixes to the stm i2c driver, I have a staging tree. I'll submit this as-is next week unless something super ground-breaking comes up. Great, I'll put this on my list.. I didn't receive your prior message, thank you for quoting it.. https://github.com/jgunthorpe/linux/commit/9981e3e622bf702394982117134bed731ffd6f7e This one is a bit out of date atm, for instance the __dev* stuff is going away. The thing that most makes me hesitant though is the config if (X86 || OF). A hardware platform or a firmware type.. What platform should this actually target? Right on the __dev stuff.. Well the 'depends on' buisness is only due to the unconditional probing of TIS_MEM_BASE for a tpm, and then the autodetection of an IRQ number. That procedure is very much X86 only. My patch removes the unconditional probe when OF support is turned on, so it is safe to use on any platform only when OF is enabled. Yes it is really wonky, but unconditionally probing HW in a driver is wonky these days too.. Jason -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] [PATCH] TPM: Work around buggy TPMs that block during continue self test
On Tue, Jan 22, 2013 at 05:29:23PM -0600, Kent Yoder wrote: > Hi Jason, > > On Wed, Nov 21, 2012 at 3:15 PM, Jason Gunthorpe > wrote: > > We've been testing an alternative TPM for our embedded products and > > found random kernel boot failures due to time outs after the continue > > self test command. > > > > This was happening randomly, and has been *very* hard to track down, but it > > looks like with this chip there is some kind of race with the > > tpm_tis_status() > > check of TPM_STS_COMMAND_READY. If things get there 'too fast' then > > it sees the chip is ready, or tpm_tis_ready() works. Otherwise it takes > > somewhere over 400ms before the chip will return TPM_STS_COMMAND_READY. > > > > Adding some delay after tpm_continue_selftest() makes things reliably > > hit the failure path, otherwise it is a crapshot. > > I've staged this patch here, please test: > > https://github.com/shpedoikal/linux.git tpmdd-01-22-13 Thanks Kent, I will try to test your branch next week, if I am able. Can you also grab https://github.com/jgunthorpe/linux/commit/98b2a198b43b41b0535200bf475160786398f114 And did you have any comments on: https://github.com/jgunthorpe/linux/commit/9981e3e622bf702394982117134bed731ffd6f7e Both were posted to the list a bit ago. Regards, -- Jason Gunthorpe (780)4406067x832 Chief Technology Officer, Obsidian Research Corp Edmonton, Canada -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] [PATCH] TPM: Work around buggy TPMs that block during continue self test
On Tue, Jan 22, 2013 at 05:29:23PM -0600, Kent Yoder wrote: Hi Jason, On Wed, Nov 21, 2012 at 3:15 PM, Jason Gunthorpe jguntho...@obsidianresearch.com wrote: We've been testing an alternative TPM for our embedded products and found random kernel boot failures due to time outs after the continue self test command. This was happening randomly, and has been *very* hard to track down, but it looks like with this chip there is some kind of race with the tpm_tis_status() check of TPM_STS_COMMAND_READY. If things get there 'too fast' then it sees the chip is ready, or tpm_tis_ready() works. Otherwise it takes somewhere over 400ms before the chip will return TPM_STS_COMMAND_READY. Adding some delay after tpm_continue_selftest() makes things reliably hit the failure path, otherwise it is a crapshot. I've staged this patch here, please test: https://github.com/shpedoikal/linux.git tpmdd-01-22-13 Thanks Kent, I will try to test your branch next week, if I am able. Can you also grab https://github.com/jgunthorpe/linux/commit/98b2a198b43b41b0535200bf475160786398f114 And did you have any comments on: https://github.com/jgunthorpe/linux/commit/9981e3e622bf702394982117134bed731ffd6f7e Both were posted to the list a bit ago. Regards, -- Jason Gunthorpe jguntho...@obsidianresearch.com(780)4406067x832 Chief Technology Officer, Obsidian Research Corp Edmonton, Canada -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] [PATCH] TPM: Work around buggy TPMs that block during continue self test
Hi Jason, On Wed, Nov 21, 2012 at 3:15 PM, Jason Gunthorpe wrote: > We've been testing an alternative TPM for our embedded products and > found random kernel boot failures due to time outs after the continue > self test command. > > This was happening randomly, and has been *very* hard to track down, but it > looks like with this chip there is some kind of race with the tpm_tis_status() > check of TPM_STS_COMMAND_READY. If things get there 'too fast' then > it sees the chip is ready, or tpm_tis_ready() works. Otherwise it takes > somewhere over 400ms before the chip will return TPM_STS_COMMAND_READY. > > Adding some delay after tpm_continue_selftest() makes things reliably > hit the failure path, otherwise it is a crapshot. I've staged this patch here, please test: https://github.com/shpedoikal/linux.git tpmdd-01-22-13 Thanks, Kent -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] [PATCH] TPM: Work around buggy TPMs that block during continue self test
Hi Jason, On Wed, Nov 21, 2012 at 3:15 PM, Jason Gunthorpe jguntho...@obsidianresearch.com wrote: We've been testing an alternative TPM for our embedded products and found random kernel boot failures due to time outs after the continue self test command. This was happening randomly, and has been *very* hard to track down, but it looks like with this chip there is some kind of race with the tpm_tis_status() check of TPM_STS_COMMAND_READY. If things get there 'too fast' then it sees the chip is ready, or tpm_tis_ready() works. Otherwise it takes somewhere over 400ms before the chip will return TPM_STS_COMMAND_READY. Adding some delay after tpm_continue_selftest() makes things reliably hit the failure path, otherwise it is a crapshot. I've staged this patch here, please test: https://github.com/shpedoikal/linux.git tpmdd-01-22-13 Thanks, Kent -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
