Firmware bug error message on Arch on Apple











up vote
4
down vote

favorite












On Arch Linux on a MacBook Air 5.1 i get the error message



DMAR-IR: [Firmware Bug]: ioapic 2 has no mapping iommu,
interrupt remapping will be disabled


when booting. I can't notice any problem, but what is this?
Does it need to be fixed and if so how?










share|improve this question






















  • This seems to be a grub issue. Which version of grub do you have?
    – C.W.
    Oct 18 '16 at 9:35












  • @C.W., the last line of my grub-install man file says 2.02~beta3.
    – Toothrot
    Oct 18 '16 at 10:07










  • ok, i will write an answer as soon as i am at home
    – C.W.
    Oct 18 '16 at 11:51















up vote
4
down vote

favorite












On Arch Linux on a MacBook Air 5.1 i get the error message



DMAR-IR: [Firmware Bug]: ioapic 2 has no mapping iommu,
interrupt remapping will be disabled


when booting. I can't notice any problem, but what is this?
Does it need to be fixed and if so how?










share|improve this question






















  • This seems to be a grub issue. Which version of grub do you have?
    – C.W.
    Oct 18 '16 at 9:35












  • @C.W., the last line of my grub-install man file says 2.02~beta3.
    – Toothrot
    Oct 18 '16 at 10:07










  • ok, i will write an answer as soon as i am at home
    – C.W.
    Oct 18 '16 at 11:51













up vote
4
down vote

favorite









up vote
4
down vote

favorite











On Arch Linux on a MacBook Air 5.1 i get the error message



DMAR-IR: [Firmware Bug]: ioapic 2 has no mapping iommu,
interrupt remapping will be disabled


when booting. I can't notice any problem, but what is this?
Does it need to be fixed and if so how?










share|improve this question













On Arch Linux on a MacBook Air 5.1 i get the error message



DMAR-IR: [Firmware Bug]: ioapic 2 has no mapping iommu,
interrupt remapping will be disabled


when booting. I can't notice any problem, but what is this?
Does it need to be fixed and if so how?







arch-linux macintosh firmware






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Oct 18 '16 at 8:48









Toothrot

796518




796518












  • This seems to be a grub issue. Which version of grub do you have?
    – C.W.
    Oct 18 '16 at 9:35












  • @C.W., the last line of my grub-install man file says 2.02~beta3.
    – Toothrot
    Oct 18 '16 at 10:07










  • ok, i will write an answer as soon as i am at home
    – C.W.
    Oct 18 '16 at 11:51


















  • This seems to be a grub issue. Which version of grub do you have?
    – C.W.
    Oct 18 '16 at 9:35












  • @C.W., the last line of my grub-install man file says 2.02~beta3.
    – Toothrot
    Oct 18 '16 at 10:07










  • ok, i will write an answer as soon as i am at home
    – C.W.
    Oct 18 '16 at 11:51
















This seems to be a grub issue. Which version of grub do you have?
– C.W.
Oct 18 '16 at 9:35






This seems to be a grub issue. Which version of grub do you have?
– C.W.
Oct 18 '16 at 9:35














@C.W., the last line of my grub-install man file says 2.02~beta3.
– Toothrot
Oct 18 '16 at 10:07




@C.W., the last line of my grub-install man file says 2.02~beta3.
– Toothrot
Oct 18 '16 at 10:07












ok, i will write an answer as soon as i am at home
– C.W.
Oct 18 '16 at 11:51




ok, i will write an answer as soon as i am at home
– C.W.
Oct 18 '16 at 11:51










2 Answers
2






active

oldest

votes

















up vote
0
down vote













In general: This feature allows the kernel to replace the remapping tables created by your BIOS.



If it's a system firmware bug, updates to Arch aren't going to fix it. You'd need to update your system firmware (BIOS/UEFI) by flashing. I personally don't recommend that. You should only do this if you really know how to flash your hardware.



The "soft" way is to disable the interrupt remapping in the kernel boot parameters. intremap=off disables the kernel interrupt remapping, which might point to your buggy bios or hardware.



First take a look atyour config with cat /proc/cmdline. Copy it to see changes later on. Now back up your /etc/default/grub by copying it to a direction you want. To make the change persistent after a reboot edit /etc/default/grub and append your kernel options to the GRUB_CMDLINE_LINUX_DEFAULT line. In your case it is intremap=off (put it into the " "). You can delete the quiet if it is in there. Save it and exit.



Now re-generate the grub.cfg file (it is generated with the parameters written in /etc/default/grub) with:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg



Reboot your system and the error should be gone. Take a look at your config with cat /proc/cmdline, your changes should be visable.






share|improve this answer





















  • It seems that the interrupt is disabled anyway. Is there a reason to do this beyond getting rid of the error message?
    – Toothrot
    Oct 18 '16 at 20:06










  • To edit grub is a temporary workaround. The error is caused by a malfunctional firmware which flags to the operating system that it supports interrupt remapping despite the fact that is unable to handle it. So you have to update your motherboards chip-firmware to really get rid of it. BUT you don't need to, especially when your system is stable now.
    – C.W.
    Oct 19 '16 at 5:57


















up vote
0
down vote













This is not an error message. Basically, Linux assumes that when there is an IO-APIC and an IOMMU, interrupt remapping must be supported. However, on this hardware it is not supported - the IO-APIC has ID 2 but the IOMMU only matches ID 0. Linux notices this situation, correctly disables interrupt remapping, and prints this notice to dmesg.






share|improve this answer





















  • All right. Doesn't that make `Firmware bug' a bit inappropriate?
    – Toothrot
    Apr 28 '17 at 13:28











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














 

draft saved


draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f317134%2ffirmware-bug-error-message-on-arch-on-apple%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
0
down vote













In general: This feature allows the kernel to replace the remapping tables created by your BIOS.



If it's a system firmware bug, updates to Arch aren't going to fix it. You'd need to update your system firmware (BIOS/UEFI) by flashing. I personally don't recommend that. You should only do this if you really know how to flash your hardware.



The "soft" way is to disable the interrupt remapping in the kernel boot parameters. intremap=off disables the kernel interrupt remapping, which might point to your buggy bios or hardware.



First take a look atyour config with cat /proc/cmdline. Copy it to see changes later on. Now back up your /etc/default/grub by copying it to a direction you want. To make the change persistent after a reboot edit /etc/default/grub and append your kernel options to the GRUB_CMDLINE_LINUX_DEFAULT line. In your case it is intremap=off (put it into the " "). You can delete the quiet if it is in there. Save it and exit.



Now re-generate the grub.cfg file (it is generated with the parameters written in /etc/default/grub) with:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg



Reboot your system and the error should be gone. Take a look at your config with cat /proc/cmdline, your changes should be visable.






share|improve this answer





















  • It seems that the interrupt is disabled anyway. Is there a reason to do this beyond getting rid of the error message?
    – Toothrot
    Oct 18 '16 at 20:06










  • To edit grub is a temporary workaround. The error is caused by a malfunctional firmware which flags to the operating system that it supports interrupt remapping despite the fact that is unable to handle it. So you have to update your motherboards chip-firmware to really get rid of it. BUT you don't need to, especially when your system is stable now.
    – C.W.
    Oct 19 '16 at 5:57















up vote
0
down vote













In general: This feature allows the kernel to replace the remapping tables created by your BIOS.



If it's a system firmware bug, updates to Arch aren't going to fix it. You'd need to update your system firmware (BIOS/UEFI) by flashing. I personally don't recommend that. You should only do this if you really know how to flash your hardware.



The "soft" way is to disable the interrupt remapping in the kernel boot parameters. intremap=off disables the kernel interrupt remapping, which might point to your buggy bios or hardware.



First take a look atyour config with cat /proc/cmdline. Copy it to see changes later on. Now back up your /etc/default/grub by copying it to a direction you want. To make the change persistent after a reboot edit /etc/default/grub and append your kernel options to the GRUB_CMDLINE_LINUX_DEFAULT line. In your case it is intremap=off (put it into the " "). You can delete the quiet if it is in there. Save it and exit.



Now re-generate the grub.cfg file (it is generated with the parameters written in /etc/default/grub) with:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg



Reboot your system and the error should be gone. Take a look at your config with cat /proc/cmdline, your changes should be visable.






share|improve this answer





















  • It seems that the interrupt is disabled anyway. Is there a reason to do this beyond getting rid of the error message?
    – Toothrot
    Oct 18 '16 at 20:06










  • To edit grub is a temporary workaround. The error is caused by a malfunctional firmware which flags to the operating system that it supports interrupt remapping despite the fact that is unable to handle it. So you have to update your motherboards chip-firmware to really get rid of it. BUT you don't need to, especially when your system is stable now.
    – C.W.
    Oct 19 '16 at 5:57













up vote
0
down vote










up vote
0
down vote









In general: This feature allows the kernel to replace the remapping tables created by your BIOS.



If it's a system firmware bug, updates to Arch aren't going to fix it. You'd need to update your system firmware (BIOS/UEFI) by flashing. I personally don't recommend that. You should only do this if you really know how to flash your hardware.



The "soft" way is to disable the interrupt remapping in the kernel boot parameters. intremap=off disables the kernel interrupt remapping, which might point to your buggy bios or hardware.



First take a look atyour config with cat /proc/cmdline. Copy it to see changes later on. Now back up your /etc/default/grub by copying it to a direction you want. To make the change persistent after a reboot edit /etc/default/grub and append your kernel options to the GRUB_CMDLINE_LINUX_DEFAULT line. In your case it is intremap=off (put it into the " "). You can delete the quiet if it is in there. Save it and exit.



Now re-generate the grub.cfg file (it is generated with the parameters written in /etc/default/grub) with:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg



Reboot your system and the error should be gone. Take a look at your config with cat /proc/cmdline, your changes should be visable.






share|improve this answer












In general: This feature allows the kernel to replace the remapping tables created by your BIOS.



If it's a system firmware bug, updates to Arch aren't going to fix it. You'd need to update your system firmware (BIOS/UEFI) by flashing. I personally don't recommend that. You should only do this if you really know how to flash your hardware.



The "soft" way is to disable the interrupt remapping in the kernel boot parameters. intremap=off disables the kernel interrupt remapping, which might point to your buggy bios or hardware.



First take a look atyour config with cat /proc/cmdline. Copy it to see changes later on. Now back up your /etc/default/grub by copying it to a direction you want. To make the change persistent after a reboot edit /etc/default/grub and append your kernel options to the GRUB_CMDLINE_LINUX_DEFAULT line. In your case it is intremap=off (put it into the " "). You can delete the quiet if it is in there. Save it and exit.



Now re-generate the grub.cfg file (it is generated with the parameters written in /etc/default/grub) with:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg



Reboot your system and the error should be gone. Take a look at your config with cat /proc/cmdline, your changes should be visable.







share|improve this answer












share|improve this answer



share|improve this answer










answered Oct 18 '16 at 17:08









C.W.

30719




30719












  • It seems that the interrupt is disabled anyway. Is there a reason to do this beyond getting rid of the error message?
    – Toothrot
    Oct 18 '16 at 20:06










  • To edit grub is a temporary workaround. The error is caused by a malfunctional firmware which flags to the operating system that it supports interrupt remapping despite the fact that is unable to handle it. So you have to update your motherboards chip-firmware to really get rid of it. BUT you don't need to, especially when your system is stable now.
    – C.W.
    Oct 19 '16 at 5:57


















  • It seems that the interrupt is disabled anyway. Is there a reason to do this beyond getting rid of the error message?
    – Toothrot
    Oct 18 '16 at 20:06










  • To edit grub is a temporary workaround. The error is caused by a malfunctional firmware which flags to the operating system that it supports interrupt remapping despite the fact that is unable to handle it. So you have to update your motherboards chip-firmware to really get rid of it. BUT you don't need to, especially when your system is stable now.
    – C.W.
    Oct 19 '16 at 5:57
















It seems that the interrupt is disabled anyway. Is there a reason to do this beyond getting rid of the error message?
– Toothrot
Oct 18 '16 at 20:06




It seems that the interrupt is disabled anyway. Is there a reason to do this beyond getting rid of the error message?
– Toothrot
Oct 18 '16 at 20:06












To edit grub is a temporary workaround. The error is caused by a malfunctional firmware which flags to the operating system that it supports interrupt remapping despite the fact that is unable to handle it. So you have to update your motherboards chip-firmware to really get rid of it. BUT you don't need to, especially when your system is stable now.
– C.W.
Oct 19 '16 at 5:57




To edit grub is a temporary workaround. The error is caused by a malfunctional firmware which flags to the operating system that it supports interrupt remapping despite the fact that is unable to handle it. So you have to update your motherboards chip-firmware to really get rid of it. BUT you don't need to, especially when your system is stable now.
– C.W.
Oct 19 '16 at 5:57












up vote
0
down vote













This is not an error message. Basically, Linux assumes that when there is an IO-APIC and an IOMMU, interrupt remapping must be supported. However, on this hardware it is not supported - the IO-APIC has ID 2 but the IOMMU only matches ID 0. Linux notices this situation, correctly disables interrupt remapping, and prints this notice to dmesg.






share|improve this answer





















  • All right. Doesn't that make `Firmware bug' a bit inappropriate?
    – Toothrot
    Apr 28 '17 at 13:28















up vote
0
down vote













This is not an error message. Basically, Linux assumes that when there is an IO-APIC and an IOMMU, interrupt remapping must be supported. However, on this hardware it is not supported - the IO-APIC has ID 2 but the IOMMU only matches ID 0. Linux notices this situation, correctly disables interrupt remapping, and prints this notice to dmesg.






share|improve this answer





















  • All right. Doesn't that make `Firmware bug' a bit inappropriate?
    – Toothrot
    Apr 28 '17 at 13:28













up vote
0
down vote










up vote
0
down vote









This is not an error message. Basically, Linux assumes that when there is an IO-APIC and an IOMMU, interrupt remapping must be supported. However, on this hardware it is not supported - the IO-APIC has ID 2 but the IOMMU only matches ID 0. Linux notices this situation, correctly disables interrupt remapping, and prints this notice to dmesg.






share|improve this answer












This is not an error message. Basically, Linux assumes that when there is an IO-APIC and an IOMMU, interrupt remapping must be supported. However, on this hardware it is not supported - the IO-APIC has ID 2 but the IOMMU only matches ID 0. Linux notices this situation, correctly disables interrupt remapping, and prints this notice to dmesg.







share|improve this answer












share|improve this answer



share|improve this answer










answered Apr 27 '17 at 21:46









jbg

1032




1032












  • All right. Doesn't that make `Firmware bug' a bit inappropriate?
    – Toothrot
    Apr 28 '17 at 13:28


















  • All right. Doesn't that make `Firmware bug' a bit inappropriate?
    – Toothrot
    Apr 28 '17 at 13:28
















All right. Doesn't that make `Firmware bug' a bit inappropriate?
– Toothrot
Apr 28 '17 at 13:28




All right. Doesn't that make `Firmware bug' a bit inappropriate?
– Toothrot
Apr 28 '17 at 13:28


















 

draft saved


draft discarded



















































 


draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f317134%2ffirmware-bug-error-message-on-arch-on-apple%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Accessing regular linux commands in Huawei's Dopra Linux

Can't connect RFCOMM socket: Host is down

Kernel panic - not syncing: Fatal Exception in Interrupt