(In reply to Jan Beulich from comment #10) > (In reply to lynda t from comment #9) > > This sound then like a definite Xen bug, and that a resolution requires > > integrating a known fix from upstream. > > Where do you see the Xen bug here? It is a bug of the firmware not to mark > for runtime use any code/data that can be accessed by EFI Runtime Services > calls. That's part of the problem -- I don't "see" any bug. There's no reference to a specific commit. I posted this ^^ as a Xen bug, correctly or not. That hasn't been changed by anyone. You've asked for Xen logs, and referenced a line in the Xen output. Then you've said the solution "is already in the upstream trees for 4.5.1:. 4.5.1 sounds like Xen. > The roadmap only talks about major releases, not stable ones afaik. We're > going to cut 4.5.1-rc1 within the next couple of weeks (preparations are > already in progress). If that rc will have this ^^ solution in it, that's good to know. Leaves me in the lurch for awhile, but that's how the dust settles. Bunch of other stuff that needs fixing will eat up time anyway ... > For one there is no "known fix", only a workaround (hence the "wontfix"). > And then ... Ok, I guess that means something to dev in detail. I read that differently -- As an end-user filing the bug, my goal is to know if/when a "fixed" version will be packaged & available somewhere we can dl and use it. ok, nm then. > ... 13.2 will pick up 4.4.3 eventually (that'll take some time, as 4.4.2 got > released pretty recently), and Factory will presumably pick up 4.5.1 once > available, i.e. the workaround will become available. I'm running a 13.2 core, with Xen 4.5.x and kernel-xen from Stable. "Not supported" I know, but it's the only config I find that's close to production ready for my hardware and needs. I'll keep an eye out for the 4.5.1 workaround -- that sounds like it'll solve this problem. Thanks.