"vmunix: target map 2: rmap ovflo, lost" errors in syslog

[Stephen Milner]

Hi all

I've got a rx7640 itanium machine running HP-UX 11.23. The server is also running virtual partitions.

I'm getting a whole load of rmap ovflo messages in the syslog file. These appear to occur on startup just before the rc scripts run.

The errors are as follows :

Sep 14 16:37:58 acpg-p-core01a vmunix: target map 2: rmap ovflo, lost [7275265,7307265)
Sep 14 16:37:58 acpg-p-core01a vmunix: target map 2: rmap ovflo, lost [7308033,7340033)
Sep 14 16:37:58 acpg-p-core01a vmunix: target map 2: rmap ovflo, lost [7340801,7372801)
Sep 14 16:37:58 acpg-p-core01a vmunix: target map 2: rmap ovflo, lost [7373569,7405569)
Sep 14 16:37:58 acpg-p-core01a vmunix: target map 2: rmap ovflo, lost [7406337,7438337)
Sep 14 16:37:58 acpg-p-core01a vmunix: target map 2: rmap ovflo, lost [7439105,7471105)
Sep 14 16:37:58 acpg-p-core01a vmunix: target map 2: rmap ovflo, lost [7471873,7503873)

Does anyone have any ideas what these messages are related to - it doesn't appear to be causing any obvious other problems on the server at the moment but i though I ought to check it out.

Thanks in Advance

Steve

[melvyn burnard]

If I recall correctly, this indicates your memory is having issues with being "fragmeneted" too much while in use.
In older OS versions, if this happened too much you could end up with a system panic (again, if I recall correctly)
May be worth logging a support call with HP to get this checked out

[Don Morris_1 · Accepted solution]

No, this is worse, actually.

target map 2 is (one of) a temporary map used while setting up the physical memory allocator. The ranges you see as lost are physical pages.
The cause of this is that vPar environments can result in very small ranges of memory being added to the allocator at a time, with high fragmentation within those ranges as to the free pages (due to early boot consumption or firmware consumption).

If I remember correctly, those pages will be consider early boot allocated [because they're being dropped from the free maps] -- but I'll do some more checking and let you know if this got a patch and if there are other complications in a couple of hours.

[Stephen Milner]

Right thanks for that - that makes sense as the errors appear just after a set of vpar messages which i've included below for info :

Sep 14 16:37:58 acpg-p-core01a vmunix: vpar_acpi_eval_obj: HID=HWP0002 UID=262 h
len=7 ulen=3
Sep 14 16:37:58 acpg-p-core01a vmunix: vpar_acpi_eval_obj: HID=HWP0002 UID=264 h
len=7 ulen=3
Sep 14 16:37:58 acpg-p-core01a vmunix: vpar_acpi_eval_obj: HID=HWP0002 UID=266 h
len=7 ulen=3
Sep 14 16:37:58 acpg-p-core01a vmunix: vpar_acpi_eval_obj: HID=HWP0002 UID=268 h
len=7 ulen=3
Sep 14 16:37:58 acpg-p-core01a vmunix: vpar_acpi_eval_obj: HID=HWP0002 UID=270 h
len=7 ulen=3
Sep 14 16:37:58 acpg-p-core01a vmunix: target map 2: rmap ovflo, lost [7275265,7
307265)
Sep 14 16:37:58 acpg-p-core01a vmunix: target map 2: rmap ovflo, lost [7308033,7
340033)

Any info on patches to resolve it would be greatly appreciated.

Thanks for your help

Cheers

Stephen

[Don Morris_1]

Ok... did some poking around.

If you end up contacting support about this, it might make everyone's lives easier if you mention that this is JAGag12178 [that isn't going to be visible to you as it was internally found and deemed not needing a fix... but there's a lot of discussion in there that doesn't need to be recreated].

On the positive side, I misremembered exactly where these pages go -- fortunately, the overflow occurs when we drop pages while transferring them from the system-wide free pool into this temporary (smaller) free map... and dropping them in this sequence leaves them in the system-wide pool. So the pages aren't leaked... they just aren't being made available for the physical allocator metadata allocations we wanted them for here. That means that while this is understandably not a bunch of messages you want to see on your buffer -- if you succeed in booting (i.e. if the physical allocator is able to find enough memory from elsewhere), there's no harm done. Those pages lost in overflow from this map were still available to the rest of the system and are in the general allocator (or used, etc. Normal).

In the original CR, this boiled down to an odd configuration in early testing of a new Itanium platform. The root of the matter is a difference in the way ACPI was presented and handled, resulting in smaller chunks of memory being presented to VM (which were being treated as larger, contiguous ranges elsewhere).

Depending on the time you want to spend, the first thing I'd check is your firmware version to be sure it is right. If you can spare the time, I'd appreciate you contacting support so they can track this with your information (partitions, versions, FW, etc.).
That's going to be very important in determining why this happened again, and I don't want to lose that information.

Thanks.

[Stephen Milner]

Don

Thanks for the information. I've logged a call and added the details you mentioned in your response. When i get an update I'll post it on here for info.

Thanks again for your help

Cheers

Stephen