Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-qemuu-rhel6hvm-amd

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.10.12 at 11:02, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Wed, 2012-10-17 at 08:41 +0100, Jan Beulich wrote:
>> So I just now realized that a similar change was already done
>> by 23736:31683aa4bfb3 and then reverted by
>> 23760:ae10d7804168. Nothing was done subsequently to
>> address the actual problem(s). It is quite obvious that the more
>> relaxed check uncovers other bugs in the ERST code, yet looking
>> at the Linux history of the corresponding file doesn't reveal any
>> fix the lack of which would explain an outright hang (rather than
>> a crash, as I would expect to be the result of e.g. the missing
>> ioremap()-s added by 0bbba38a61283a55f2061ab3e0910c572d19f462.
>> 
>> Most of the other changes are cosmetic or pstore related, so I
>> wonder whether instead of reverting again we should try pulling
>> in this one extra fix.
> 
> Worth a go. I assume this issue isn't related to the typo you found this
> morning?

I didn't find any typo; the original author of the Linux side patch
pointed out a typo in the commit message (which was copied
verbatim from the Linux side).

>> If reverting is preferred (or turns out necessary if that second
>> fix doesn't help), we should settle on the disposition of the whole
>> APEI/ERST code, as my conclusion is that it is pretty much
>> unmaintained since its original contribution over two years ago.
> 
> If we revert we should leave a big fat comment pointing to this and/or
> the previous discussion to stop the next guy doing the same thing.

We should rather decide whether this should get fixed, or the
code ripped out (decision mainly depending on the original
contributer - Intel - being willing to fix the code).

> The comment in 26060:4fc87c2f31a0 seems to suggest that the issue is
> (possibly) only a problem non-production or early machines, if that's
> the case it doesn't seem worth worrying about ERST not functioning on
> those Assuming the system works generally I think the world can live
> without the ERST facility being available on them.

It's actually the other way around - prior to the patch, to code
accepted only the value seen on some early systems, whereas
the patch gets it in line with the spec, but still permits the wrong
value to be used. Which implies that the AMD systems the tester
uses use the correct value (and hangs because we now don't
reject that anymore).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel