On Fri, 15 Aug 2008 14:50:01 -0400 Kenneth Goldman <kgoldman@us.ibm.com> wrote:We try very very hard to not crash on failure. Our disk layer will retry, reset, change cable speeds and if that fails and you are running raid with multipaths or sufficient mirrors continue. We capture processor exceptions and when possible log and continue although most CPU failures report with the context corrupt. We log and the EDAC layer handles as much as it possible can for memory errors (actually we could be a bit more selective here and there are proposals to go further) The Linux userbase ranges from fault tolerant systems like Stratus to dodgy cheapo boards from iffy cheap and cheerful computer merchants so it makes sense to try and be robust. In your TPM case being robust against the TPM ceasing to respond certainly is worthwhile so that at least you return an error on failure rather than the box dying. You may well not be able to get the chip back in order without a hardware change/reboot. Alan --
| Greg Kroah-Hartman | [PATCH 008/196] Chinese: add translation of volatile-considered-harmful.txt |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in |
| Andrew Morton | -mm merge plans for 2.6.23 |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Herbert Xu | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Rémi Denis-Courmont | [PATCH 01/14] Phonet global definitions |
