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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.10.12 at 11:04, Keir Fraser <keir@xxxxxxx> wrote:
> On 17/10/2012 08:41, "Jan Beulich" <JBeulich@xxxxxxxx> 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.
>> 
>> 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.
> 
> Perhaps we reverted before because we decided that this advertised table
> size was a bug, and handling it just opened us to other bugs lurking in the
> table?

As just said in the response to Ian - originally, only a spec violating
vale was accepted here, whereas with the change we also accept
the proper value. The patch itself was prompted by a bug report
we got that on a spec conformant system the "ERST table is invalid"
message was seen.

Jan


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