Hi all! Giving my two cents! First of all, it's not an "error", it's a "warning". This small word change means a lot of meanning change: it's not a failure, it just warns you about a situation. Sooo, dont worry too much and take a coffee/reading when you see "warning", move your ass quick when see "error", and run in circles with your arms in the air when see "panic". :)
About DMAR: As far as i know, this mapping is a bios step where hardware address are mapped and placed into memory for later use in software communications with hardware. That way, sofware can communicate through this mapping without know which physical hardware address the device has. Take into account that the same device connected to different port changes its hardware address. Without interrupts, and address mapping, software "that talks to hardware" like drivers, must be designed for each computer design individually! not so much "PC-compatible" software then :S So that mapping allows, for example, move a piece of hardware from one port to another, and the software will keep its ability to speak to the hardware (it speak through the map), regardless it has change its physical port and hardware address. In the old years, you had to map this by hand in the BIOS. That's said, when you moved a pci card to another port, you went to BIOS and remap it to get assigned to the same interrupt. That way the software didnt notice the hardware change, and all keept working as expected. Nowadays you can do it the old way, but better now: the operative system is able to do this mapping dynamicly. It can change this mapping, and it's great, because OS knows which previous hardware had and which ports it was connected to. That way (today) you move a card from one port to another, and you dont have to enter BIOS. The OS see the move, and remap the interrupt to keep the hardware in the same logical address. Then the software dont notice the change, and all works as expected. So something goes wrong when your linux remap the assigned interruptions. Is my hardware broken? not necessarly. How this keep working? linux should be using the mapping given by the bios, and not remmaping it (like in '90s! :) Im going to have problems? probably not. So in the case of a laptop this remapping doesnt seem to be very important, because hardware changes are less common that in desktop computers. Also interrupt conflicts are less common in laptops. With desktop computers you can attach expansion cards (scsi for example), and end up with a lot of hardware, that can exhaust BIOS hability for mapping, and generate conflicting interrupts (one address for two pieces of hardware). So DMAR is not working in your laptop, but as far as "your hardware communications" are ok, so everything is ok. Keep an eye in logs if you introduce _hardware_changes_ that need _modules_ to work. This could be problematic then. Regards! D El jue, 12-11-2015 a las 08:25 -0500, Bruno Dantas escribió: > It seems that interrupt mapping is done by BIOS (or Libreboot in my case) > first, then the linux kernel remaps things for whatever reason [0]. I know > nothing about this low-level stuff, but because the laptop is working despite > the DMAR failure, I ventured a guess that the interrupt remapping done by the > kernel is not strictly necessary. > > Therefore, I looked at the complete list of kernel boot parameters [1] and > tried all the ones that sounded promising. I found that intremap=off makes > the boot-time DMAR error go away! I tested all peripherals and everything > seems to be working fine. Relevant lines from dmesg here: > http://pastebin.com/KCGVaf8U > > In some cases, this DMAR error is related to faulty chipsets [2]. I guess the > question that remains is whether my T400 (or its Libreboot) is defective in > some way or is the DMAR failure something that is expected to happen on every > T400 with Libreboot? If there is nothing wrong with my hardware or my > Libreboot flash, is booting with intremap=off ill-advised for any reason? > > [0] > https://unix.stackexchange.com/questions/84880/what-is-meant-by-interrupt-remapping-in-linux > [1] https://www.kernel.org/doc/Documentation/kernel-parameters.txt > [2] https://www.netiq.com/support/kb/doc.php?id=7014344 > >
