On Thu, Nov 17, 2016 at 10:01:15AM -0500, Boris Ostrovsky wrote:
> On 11/16/2016 05:08 AM, Jan Beulich wrote:
> On 15.11.16 at 21:51, wrote:
> >> On 11/15/2016 03:44 PM, Andrew Cooper wrote:
> >>> On 15/11/2016 20:39, Boris Ostrovsky wrote:
> On 11/15/2016
On 11/16/2016 05:08 AM, Jan Beulich wrote:
On 15.11.16 at 21:51, wrote:
>> On 11/15/2016 03:44 PM, Andrew Cooper wrote:
>>> On 15/11/2016 20:39, Boris Ostrovsky wrote:
On 11/15/2016 02:45 PM, Andrew Cooper wrote:
> On 15/11/16 19:34, Boris Ostrovsky
>>> On 15.11.16 at 21:51, wrote:
> On 11/15/2016 03:44 PM, Andrew Cooper wrote:
>> On 15/11/2016 20:39, Boris Ostrovsky wrote:
>>> On 11/15/2016 02:45 PM, Andrew Cooper wrote:
On 15/11/16 19:34, Boris Ostrovsky wrote:
> In addition to running out of e820
On 11/15/2016 03:44 PM, Andrew Cooper wrote:
> On 15/11/2016 20:39, Boris Ostrovsky wrote:
>> On 11/15/2016 02:45 PM, Andrew Cooper wrote:
>>> On 15/11/16 19:34, Boris Ostrovsky wrote:
In addition to running out of e820 entries on that large machine that
Alex was referring to in [0] he
On 15/11/2016 20:39, Boris Ostrovsky wrote:
> On 11/15/2016 02:45 PM, Andrew Cooper wrote:
>> On 15/11/16 19:34, Boris Ostrovsky wrote:
>>> In addition to running out of e820 entries on that large machine that
>>> Alex was referring to in [0] he is also running out of ACPI fixmap space
>>> while
On 11/15/2016 02:45 PM, Andrew Cooper wrote:
> On 15/11/16 19:34, Boris Ostrovsky wrote:
>> In addition to running out of e820 entries on that large machine that
>> Alex was referring to in [0] he is also running out of ACPI fixmap space
>> while parsing MADT (the box has *lots* of processors).
On 15/11/16 19:34, Boris Ostrovsky wrote:
> In addition to running out of e820 entries on that large machine that
> Alex was referring to in [0] he is also running out of ACPI fixmap space
> while parsing MADT (the box has *lots* of processors). The
> quick-and-dirty solution is to increase