Can not request iomem region

hisaltesse

Well-Known Member
Mar 4, 2009
227
2
58
APEI: Can not request iomem region <00000000bf7b85ea-00000000bf7b85ec> for GARs.

I just installed proxmox 2.0rc1 on an Intel Xeon X5650 @ 2.67GHz with 24GB of RAM.
And set the maxroot to 45G
The main storage is on LSI Megaraid RAID10 with 8 drives - total 445GB.


The first boot message I get is:

APEI: Can not request iomem region <00000000bf7b85ea-00000000bf7b85ec> for GARs.
Loading, please wait…
megasas: IOC Init cmd success


Any idea what this means ?

Here is a screenshot.

can not request iomem issue.png

Here is the booting video

http://screencast.com/t/imUdnqK1Cqva
 
Last edited:
It looks like proxmox is not able to read the entire memory? I wonder what negative implications this may have. We need a solution to this.
 
It looks like proxmox is not able to read the entire memory? I wonder what negative implications this may have. We need a solution to this.

Seem to be a motherboard/firmware related problem.

Note: I have no such hardware, so it is unlikely that i can fix that bug (I don't even know what hardware you use).

Besides, have you observed any real problem (besides that warning)?
 
This is the hardware I use:

"Supermicro SYS-1026T-6RF+ 1U Intel Xeon5600/5500 DDR3 PCIE2 750W Black
"
Intel CPU BX80614X5650 Xeon 6 Core X5650 2.66GHz LGA1366 12MB 6.40GT Retail


See specs attached.

image001-1.jpgimage002-1.jpg
 
APEI: Can not request iomem region <00000000bf7b85ea-00000000bf7b85ec> for GARs.

I have a feeling that Proxmox is get able to read all the memory.


APEI: Can not request iomem region <00000000bf7b85ea-00000000bf7b85ec> for GARs.


I am attaching some logs if that could help.

View attachment promoxbootlog.zip
 
Ok guys:

We were supposed deploy a new production server tomorrow with Proxmox 2.0.
However with this new issue we cannot deploy Proxmox 2.0.


We have decided to delay the production server release by a few days while waiting to receive a fix from you guys.

I am available every day to test any fix you may have to this issue.

Unfortunately we cannot keep delaying this deployment. So we have only until the end of this coming week (until March 9th) to get a fix.
If we do not have a fix by then we will have no choice but to use a different virtualization vendor and therefore won't even have the server available anymore to test and confirm whether your fix work.

So it would be greatly appreciated if you guys could give this issue a priority attention and use the next few days to allow me to help you test a fix to this issue.

Thank you.
 
So it would be greatly appreciated if you guys could give this issue a priority attention and use the next few days to allow me to help you test a fix to this issue

There seems to be some miss-understanding what 'open-source' is. It is perfectly valid to make money with this software, but please don't expect that we fix all your problems for free. If you need commercial support you should buy a subscription - else it is difficult to allocate resources.
 
Hi, I'll try to help you.

can you add in your /boot/grub/grub.cfg

linux /vmlinuz-2.6.32-7-pve root=/dev/mapper/pve-root ro debug ignore_loglevel

And tell me if you have more logs.

I'm currently compiling a kernel without APEI. (but centos 6.2 have APEI enable in kernel, so this is strange that is booting fine on it).
I'll post it in today.



UPDATE :

I didn't read correctly your post, but you are booting fine right ? Do you have instability problems ?
APEI support is really new (august 2011) I think, so maybe some problem can exist with some motherboards.


UPDATE:

you could also try to pass acpi_disabled=1 to your grub.conf
 
Last edited:
Hi, I'll try to help you.

UPDATE :

I didn't read correctly your post, but you are booting fine right ? Do you have instability problems ?
APEI support is really new (august 2011) I think, so maybe some problem can exist with some motherboards.


UPDATE:

you could also try to pass acpi_disabled=1 to your grub.conf

Thank you spirit,

The issue is that we are not trying to find a way to escape the issue here because we do not understand what this means and the impact.

We would rather have a real solution. Why would other OS install find without this issue but not proxmox? Clearly something is missing. We would rather not settle with disabling this feature if it help.

For example a few years ago we bought a great piece of hardware with Intel 5500 series in it. In production with proxmox we started having huge spikes of loads when the server was on load with less than 20 containers. Several times a day the server would suddenly slow down and load would go to a very high number. The only solution to this issue ended up being disabling the HyperThreading.

So what good was it to buy an expensive server with HT and having to disable it because of an unknown issue with the software?

This time we are not going to settle for an issue that could cause all kinds of problems in production when the server is under considerable load.
 
There seems to be some miss-understanding what 'open-source' is. It is perfectly valid to make money with this software, but please don't expect that we fix all your problems for free. If you need commercial support you should buy a subscription - else it is difficult to allocate resources.

Diermar I see your point and that is expected.

However I would like to balance it with my thoughts.

1. You probably won't get much support contact in general unless on production servers. So if someone can't go to production with proxmox, your chance of selling a support contract to that person is very slim.

2. Yes it is open source but the community helps you guys a great deal with testing. So both party are getting something out of it.

3. I offered to spend time to help you testing this issue daily and even giving you access to the server as needed. That is also for me time and effort that i'd rather not deal with… Other people would simply go to another vendor.

So ultimately whether I get a support contract now or not, if you do not help on this issue (that other have but probably did not pay attention to the boot log and didn't realize that this was happening) right now, you would be certainly shutting down your chances of me getting one, especially because I'll have no choice but deploying this server with another vendor.

But I fully understand your point and your point is valid as well.
 
Last edited:
2. Yes it is open source but the community helps you guys a great deal with testing. So both party are getting something out of it.

In a perfect (open source) world you would send me a fix (patch) for the problem ;-)
 
In a perfect (open source) world you would send me a fix (patch) for the problem ;-)

Good point except that I don't fall under the developer's category of open source contributors.

The question is:
Whether you can find a fix to this in a matter of days, in which case I would not mind even paying for a support ticket. But provided that you feel confident that you guys can nail this down within 5 days with a real fix, not a patch that just silences the issue.

I don't mean to sound rushy but the only reason is that we have a deadline that we have been pushing twice already because Proxmox 2.0 is not ready and buying support would only be worth it for us if proxmox can delivery by the end of this coming week and that we can use it.

Do you guys understand why proxmox is showing some incompatibility at this level? Have you considered building ACPI/APEI compatibility with proxmox?
 
Hyperthreading should be turned off on any Visualization server host regardless of OS being used. VMware even make a point of recommending it. Thats hardly something that can be blamed on Proxmox. Find a better example.
 
Good point except that I don't fall under the developer's category of open source contributors.

The question is:
Whether you can find a fix to this in a matter of days, in which case I would not mind even paying for a support ticket. But provided that you feel confident that you guys can nail this down within 5 days with a real fix, not a patch that just silences the issue.

I don't mean to sound rushy but the only reason is that we have a deadline that we have been pushing twice already because Proxmox 2.0 is not ready and buying support would only be worth it for us if proxmox can delivery by the end of this coming week and that we can use it.

Do you guys understand why proxmox is showing some incompatibility at this level? Have you considered building ACPI/APEI compatibility with proxmox?

Hi,
I'm a little bit astonished:
1. You have an issue, which the pve-staff can't reproduce
2. You don't try the test which spirit wrote
3. but you request a fast and real fix?!

How should that work? You wrote, that the mainboard can not be the issue - but it's an supermicro (and my meaning about bios-quality on supermicro boards are very low).
One big advantage of pve against other virtualisation-sw (like vmware), is that not only few systems are supported. But if you need an full supported system you also need hardware, which they tested (like the intel modular server).

Udo
 
Hi,
APEI support is really new (kernel 2.6.31), and I read a lot a user complaint about this error on fedora 16-17 with supermicro board.
This seem to be related to a bad firmware implementation (from supermicro).

But this doesn't impact your system, you won't have error reports from acpi. (just like other old kernel without APEI).

From my experience, supermicro board are pretty bad for bios update.(something I need to wait 1year for bios bug corrections).
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!