[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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?

> 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.

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.

Ian.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.