DMAR:Host address width 36 DMAR:DRHD base: 0x00000000000000 flags: 0x1 IOMMU 0: ver 5:3 cap f0003d3cf000e2c3 ecap: f000ff54f000ff53 DMAR:RMRR base: 0x0000007be00000 end:0000007fffffff flag: 0x1 DMAR: No ATSR found DRHD: handling fault status reg f0003d30 Kernel panic - not syncing: DMAR hardware is malfunctioning Kernel 2.6.31.5-122.fc12.i686 worked with this warning: Nov 8 16:34:28 localhost kernel: DMAR:Host address width 36 Nov 8 16:34:28 localhost kernel: DMAR:DRHD base: 0x00000000000000 flags: 0x1 Nov 8 16:34:28 localhost kernel: ------------[ cut here ]------------ Nov 8 16:34:28 localhost kernel: WARNING: at drivers/pci/dmar.c:183 dmar_table_init+0x133/0x343() (Not tainted) Nov 8 16:34:28 localhost kernel: Hardware name: Aspire 1810T Nov 8 16:34:28 localhost kernel: Your BIOS is broken; DMAR reported at address zero! Nov 8 16:34:28 localhost kernel: BIOS vendor: INSYDE; Ver: v0.3120; Product Version: v0.3120 Nov 8 16:34:28 localhost kernel: Modules linked in: Nov 8 16:34:28 localhost kernel: Pid: 1, comm: swapper Not tainted 2.6.31.5-122.fc12.i686 #1 Nov 8 16:34:28 localhost kernel: Call Trace: Nov 8 16:34:28 localhost kernel: [<c0436d93>] warn_slowpath_common+0x70/0x87 Nov 8 16:34:28 localhost kernel: [<c09aa667>] ? dmar_table_init+0x133/0x343 Nov 8 16:34:28 localhost kernel: [<c0436de8>] warn_slowpath_fmt+0x29/0x2c Nov 8 16:34:28 localhost kernel: [<c09aa667>] dmar_table_init+0x133/0x343 Nov 8 16:34:28 localhost kernel: [<c098f6b4>] ? pci_iommu_init+0x0/0x11 Nov 8 16:34:28 localhost kernel: [<c09ab2c1>] intel_iommu_init+0xa/0x2b6 Nov 8 16:34:28 localhost kernel: [<c098f6bc>] pci_iommu_init+0x8/0x11 Nov 8 16:34:28 localhost kernel: [<c0401143>] do_one_initcall+0x51/0x13f Nov 8 16:34:28 localhost kernel: [<c0989372>] kernel_init+0x19c/0x1ed Nov 8 16:34:28 localhost kernel: [<c09891d6>] ? kernel_init+0x0/0x1ed Nov 8 16:34:28 localhost kernel: [<c04041a7>] kernel_thread_helper+0x7/0x10 Nov 8 16:34:28 localhost kernel: ---[ end trace 6d450e935ee1897c ]--- Kernel -127 fails to boot with a kernel panic. Did somebody maybe remove the WARNING in drivers/pci/dmar.c for kernel -127?
I have the same problem - with kernel 2.6.31.5-122.fc12.i686, I get this oops but it does boot: DMAR:Host address width 36 DMAR:DRHD base: 0x00000000000000 flags: 0x1 ------------[ cut here ]------------ WARNING: at drivers/pci/dmar.c:183 dmar_table_init+0x133/0x343() (Not tainted) Hardware name: HP Pavilion dv4 Notebook PC Your BIOS is broken; DMAR reported at address zero! BIOS vendor: Hewlett-Packard; Ver: F.55; Product Version: F.55 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.31.5-122.fc12.i686 #1 Call Trace: [<c0436d93>] warn_slowpath_common+0x70/0x87 [<c09aa667>] ? dmar_table_init+0x133/0x343 [<c0436de8>] warn_slowpath_fmt+0x29/0x2c [<c09aa667>] dmar_table_init+0x133/0x343 [<c098f6b4>] ? pci_iommu_init+0x0/0x11 [<c09ab2c1>] intel_iommu_init+0xa/0x2b6 [<c098f6bc>] pci_iommu_init+0x8/0x11 [<c0401143>] do_one_initcall+0x51/0x13f [<c0989372>] kernel_init+0x19c/0x1ed [<c09891d6>] ? kernel_init+0x0/0x1ed [<c04041a7>] kernel_thread_helper+0x7/0x10 ---[ end trace 93d72a36b9146f22 ]--- Kernel 2.6.31.5-127.fc12.i686 panics with this error message when I try to boot: DRHD: handling fault status reg f0003d63 Kernel panic - not syncing: DMAR hardware is malfunctioning I'm sure if this is useful information but I believe that my HP laptop uses an Insyde BIOS as well.
Workaround seems to be to add "intel_iommu=off" to the boot commandline.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
getting the same error here. screen halts on this message: DRHD: handling fault status reg f0003d30 Kernel panic - not syncing: DMAR hardware is malfunctioning I have three kernels installed: kernel-PAE-2.6.32-0.48.rc7.git1.fc13.i686 kernel-PAE-2.6.31.5-127.fc12.i686
sorry - hit wrong key - also have kernel-PAE-2.6.31.5-115.fc12.i686 system does not boot with the previous two, but does with this one.
The WARNING and abort is still there -- it's just done much earlier during the boot, and was tested by various people who suffer from having HP hardware. I don't understand why it isn't triggering in your system. I'm building a scratch kernel with a little extra debugging, which should _definitely_ refuse to enable the IOMMU. Please could you let me have the full output of 'dmesg' after it boots. http://koji.fedoraproject.org/koji/taskinfo?taskID=1812987 diff -u b/drivers/pci/dmar.c b/drivers/pci/dmar.c --- b/drivers/pci/dmar.c +++ b/drivers/pci/dmar.c @@ -175,6 +175,15 @@ int ret = 0; drhd = (struct acpi_dmar_hardware_unit *)header; + if (!drhd->address) { + /* Promote an attitude of violence to a BIOS engineer today */ + WARN(1, "Your BIOS is broken; DMAR reported at address zero!\n" + "BIOS vendor: %s; Ver: %s; Product Version: %s\n", + dmi_get_system_info(DMI_BIOS_VENDOR), + dmi_get_system_info(DMI_BIOS_VERSION), + dmi_get_system_info(DMI_PRODUCT_VERSION)); + return -ENODEV; + } dmaru = kzalloc(sizeof(*dmaru), GFP_KERNEL); if (!dmaru) return -ENOMEM; @@ -602,6 +611,7 @@ if (entry_header->type == ACPI_DMAR_TYPE_HARDWARE_UNIT) { drhd = (void *)entry_header; + printk("DRHD at %llx\n", drhd->address); if (!drhd->address) { /* Promote an attitude of violence to a BIOS engineer today */ WARN(1, "Your BIOS is broken; DMAR reported at address zero!\n" @@ -616,7 +626,8 @@ entry_header = ((void *)entry_header + entry_header->length); } - return 1; + printk("IOMMU was detected, but faking its absence...\n"); + return 0; } void __init detect_intel_iommu(void)
Same thing here. Darn Insyde BIOS !@#$%^, will add information ASAP
Please install (--nodeps) the kernel from http://koji.fedoraproject.org/koji/getfile?taskID=1812989&name=kernel-2.6.31.6-136.hptest.fc12.x86_64.rpm and show me the full dmesg as it boots.
Created attachment 369998 [details] kernel dmesg 2.6.31.6-136.hptest.fc12.x86_64 Kernel dmesg
Created attachment 369999 [details] BIOS DMAR.dsl I'm having the same problem.. kernel 2.6.31.5-127 bugs out when booted on this laptop, unless intel_iommu=off is used. oh, this is an Acer AS1410 with Intel CULV/SU2300 processor, and Insyde Bios v0.3120
@tdavis THats the same Machine & BIOS I'm using. Trying to download F12 x86_64 to test the kernel
Created attachment 370019 [details] dmesg output with test kernel dmesg output with test kernel
(In reply to comment #11) > @tdavis > > THats the same Machine & BIOS I'm using. Trying to download F12 x86_64 to test > the kernel whoa, that IS the same. This laptop bios also has no p-states for the CPU, and the mic input doesn't work under Fedora12..
(In reply to comment #13) > This laptop bios also has no p-states for the CPU, and the mic input doesn't > work under Fedora12.. The mic issue might be Bug #471331. Comment #21 of that bug solved the mic input problem for my laptop.
Er... first we return a failure to detect the IOMMU. Then it gets initialised anyway. That's.... special. Should be fixed in kernel-2.6.31.6-137.fc12, building at http://koji.fedoraproject.org/koji/taskinfo?taskID=1813812 How in $DEITY's name did the various testers for bug #524808 _all_ manage to report success with -127?
(In reply to comment #15) > > Should be fixed in kernel-2.6.31.6-137.fc12, building at > http://koji.fedoraproject.org/koji/taskinfo?taskID=1813812 > booted and running fine without intel_iommu=off. I'll attach a dmesg..
Created attachment 370148 [details] kernel dmesg 2.6.31.6-137.fc12.x86_64 Running with no intel_iommu cmdline option.
*** Bug 538552 has been marked as a duplicate of this bug. ***
This issue is also affecting me; however, I don't have an HP notebook. My motherboard is an ASUS P6T6 WS Revolution, and I see substantially the same kernel panic when booting -127. Booting -137 works fine, and booting -127 with the intel_iommu=off workaround also works fine. http://www.smolts.org/client/show/pub_a7865093-daec-443a-933e-62669a30997a
good lord. have to follow up with the testers. david, is it possible it only continues to be broken in _some_ cases, for some reason? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I can't see how that could be the case.
if we got 'em to install the hptest kernel and boot with it, that would tell us, I guess. i'll follow up on 524707. I just want to know what the hell happened here... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
duh...524808, of course. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I'm back and I've been playing around with different BIOSes, something that ASUS seems to have a lot of trouble with. Here are my results. After reading bug 524808 I'm going to do some more testing with VT-d disabled (it was enabled for all tests here). ASUS P6T6 WS Revolution motherboard; BIOSes tested were 0311 and 0507 (latest) 0311 BIOS with -127 kernel requires intel_iommu=off to boot. Panic without option. No kernel oops is logged. 0311 BIOS with -137 kernel requires intel_iommu=off to boot. Panic without option. No kernel oops is logged. 0507 BIOS with -127 kernel requires intel_iommu=off to boot. Panic without option. No kernel oops is logged. 0507 BIOS with -137 kernel does not require option to boot. A kernel oops is logged: ------------[ cut here ]------------ WARNING: at drivers/pci/intel-iommu.c:3724 init_dmars+0x331/0x6f1() (Not tainted) Hardware name: System Product Name Your BIOS is broken; DMA routed to ISOCH DMAR unit but no TLB space. BIOS vendor: American Megatrends Inc.; Ver: 0507 ; Product Version: System Version Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.31.5-127.fc12.x86_64 #1 Call Trace: [<ffffffff81051694>] warn_slowpath_common+0x84/0x9c [<ffffffff81051703>] warn_slowpath_fmt+0x41/0x43 [<ffffffff8173d345>] init_dmars+0x331/0x6f1 [<ffffffff8173d970>] intel_iommu_init+0x26b/0x32a [<ffffffff8171bb41>] ? pci_iommu_init+0x0/0x21 [<ffffffff8171bb4f>] pci_iommu_init+0xe/0x21 [<ffffffff8100a069>] do_one_initcall+0x5e/0x162 [<ffffffff81714750>] kernel_init+0x219/0x273 [<ffffffff81012daa>] child_rip+0xa/0x20 [<ffffffff81714537>] ? kernel_init+0x0/0x273 [<ffffffff81012da0>] ? child_rip+0x0/0x20 ---[ end trace f17e946d22a56015 ]---
I see it now (cdub pointed me at the answer). For people with ram > 4GiB, when the IOMMU is not "detected" in early boot the swiotlb is initialised -- and _that_ means that the IOMMU isn't later initialised. For people with less RAM, the swiotlb isn't needed so it isn't set up. And _then_ the IOMMU init does actually go ahead (even though we claimed not to have detected one). So the original patch just made it work for those with more than about 2½GiB of RAM, while breaking it for those with less RAM who weren't affected before. Grrr.
I am doing a dual boot on my laptop, but after loading the DVD burned disc. I selected install. Then this error pop out... Can anyone solve this error below? After having this error, CRTL-ALT-DEL can't even work. I had to use brute force to shutdown my laptop. Is there way to solve this problem? or I have to wait for the new patch to come? Hardware name: HP Pavilion dv4 Notebook PC Your BIOS is broken; DMAR reported at address zero! BIOS vendor: Hewlett-Packard; Ver: F.55; Product Version: F.55 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.31.5-122.fc12.i686 #1 Call Trace: [<c0436d93>] warn_slowpath_common+0x70/0x87 [<c09aa667>] ? dmar_table_init+0x133/0x343 [<c0436de8>] warn_slowpath_fmt+0x29/0x2c [<c09aa667>] dmar_table_init+0x133/0x343 [<c098f6b4>] ? pci_iommu_init+0x0/0x11 [<c09ab2c1>] intel_iommu_init+0xa/0x2b6 [<c098f6bc>] pci_iommu_init+0x8/0x11 [<c0401143>] do_one_initcall+0x51/0x13f [<c0989372>] kernel_init+0x19c/0x1ed [<c09891d6>] ? kernel_init+0x0/0x1ed [<c04041a7>] kernel_thread_helper+0x7/0x10 ---[ end trace 93d72a36b9146f22 ]--- Kernel 2.6.31.5-127.fc12.i686 panics with this error message when I try to boot: DRHD: handling fault status reg f0003d63 Kernel panic - not syncing: DMAR hardware is malfunctioning
What happened when you tried the workaround described in comment #2?
(In reply to comment #27) > What happened when you tried the workaround described in comment #2? Erh... I am new to fedora, linux =) can I ask how to add "intel_iommu=off" to the boot command line?
david: so, for errata purposes - we're now in the position where all the same potentially-affected-machines I compiled a list of are broken, except now broken in the *low* RAM case rather than the *high* RAM case? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
kiro: you need to press tab at the bootloader screen (the one where you get the choice of just installing, or doing a safe video mode install, etc). then follow the instructions to edit the command line for the kernel that's about to boot, and just add that option to the end. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #28) > Erh... I am new to fedora, linux =) can I ask how to add "intel_iommu=off" to > the boot command line? When you boot the installation DVD you will see the boot screen where it asks if you want to install, or rescue, and it says: "Press [Tab] to edit options". Now press Tab. The boot command line will appear. Tap the space bar once, and then type in intel_iommu=off, then press Enter.
(In reply to comment #31) > (In reply to comment #28) > > Erh... I am new to fedora, linux =) can I ask how to add "intel_iommu=off" to > > the boot command line? > > When you boot the installation DVD you will see the boot screen where it asks > if you want to install, or rescue, and it says: "Press [Tab] to edit options". > Now press Tab. The boot command line will appear. Tap the space bar once, and > then type in intel_iommu=off, then press Enter. Thank!! ^_^ I am greatly appreciate it. But I notice every time, I boot up,I need to type the command. Is there way to startup without typing the command line??
> Thank!! ^_^ > I am greatly appreciate it. > But I notice every time, I boot up,I need to type the command. Is there way to > startup without typing the command line?? add that line in /boot/grub/menu.lst
when adding intel_iommu=off, the system boot correctly, but i get a lot of kernel oops, and after some time the system freezes. ------------[ cut here ]------------ WARNING: at drivers/pci/dmar.c:593 check_zero_address+0x72/0x8e() (Not tainted) Hardware name: HP Compaq 6730s Your BIOS is broken; DMAR reported at address zero! BIOS vendor: Hewlett-Packard; Ver: 68PZU Ver. F.09; Product Version: F.09 Modules linked in: Pid: 0, comm: swapper Not tainted 2.6.31.5-127.fc12.i686 #1 Call Trace: [<c0436d93>] warn_slowpath_common+0x70/0x87 [<c09aa518>] ? check_zero_address+0x72/0x8e [<c0436de8>] warn_slowpath_fmt+0x29/0x2c [<c09aa518>] check_zero_address+0x72/0x8e [<c09aa586>] detect_intel_iommu+0x11/0x56 [<c098f6cd>] pci_iommu_alloc+0x8/0xa [<c099c963>] mem_init+0xe/0x28e [<c098972b>] start_kernel+0x1a4/0x330 [<c09893c3>] ? unknown_bootoption+0x0/0x18e [<c0989070>] i386_start_kernel+0x70/0x77 ---[ end trace a7919e7f17c0a725 ]---
Enabling VT-d in the BIOS should also be sufficient to make the problem go away, without having to change the kernel command line. Athmane, your problems when the IOMMU is turned off are not part of this bug; please file them in a separate bug with the full dmesg. The warning you filed in comment #34 is harmless. If you're seeing _real_ oopses, please show them in the new bug you file.
(In reply to comment #33) > > Thank!! ^_^ > > I am greatly appreciate it. > > But I notice every time, I boot up,I need to type the command. Is there way to > > startup without typing the command line?? > > add that line in /boot/grub/menu.lst I had try to add it but after I reboot the whole fedora crash. Which line should I add at /boot/grub/menu.lst?
mine look like this: default=0 timeout=0 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title Fedora (2.6.31.5-127.fc12.i686) root (hd0,0) kernel /vmlinuz-2.6.31.5-127.fc12.i686 ro root=/dev/mapper/VolGroup00-LogVol00 LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=fr rhgb quiet intel_iommu=off initrd /initramfs-2.6.31.5-127.fc12.i686.img
(In reply to comment #37) > mine look like this: > > default=0 > timeout=0 > splashimage=(hd0,0)/grub/splash.xpm.gz > hiddenmenu > title Fedora (2.6.31.5-127.fc12.i686) > root (hd0,0) > kernel /vmlinuz-2.6.31.5-127.fc12.i686 ro root=/dev/mapper/VolGroup00-LogVol00 > LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=fr rhgb > quiet intel_iommu=off > initrd /initramfs-2.6.31.5-127.fc12.i686.img Hi! I had try to follow your method but I still cant boot the fedora12, now the kernel crash again. It gave me some Unicode characters.
athmane: I believe it was noted in the other bug that setting 'iommu=soft' may give better behaviour than 'intel.iommu=off'. you could try that, also, before filing a new bug. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
david: I believe we established that some affected BIOSes offer no option to enable VT-d in the BIOS :/ -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
hi, I seem to have the same problem but mine doesn't boot (no grub) here's what i get : DRHD: handling fault status reg f0006800 Kernel panic - not syncing: DMAR hardware is malfunctioning using last liveCD image of F12 (same kernel as reported here) on laptop HP6730s.
j: that looks like a different error from what others are seeing. Can you please file a new bug? Thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Same.. I also got the same error when I use the live CD image. From comment 41 My laptop is HP dv4
as I said, that's not the same error, so please file a new bug. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #44) > as I said, that's not the same error, so please file a new bug. I do think it's the same problem, even though it's not exactly the same error message... I had the problem explained in comment 41, and got my Live CD (actually USB) to boot by disabling the intel_iommu in the kernel command line. After updating to the kernel from comment 15 booting without intel_iommu=off though showing the errors described here. Hardware: Acer Aspire Timeline 1810T, Intel SU3500 processor (like the bug-reporter) BIOS: INSYDE v0.3108 (even slightly older)
thanks for your help, i'm filing a new bug.
I agree with Luit - mine is an Acer Aspire Timeline 3810T. adding intel_iommu=off to the grub config "fixes" the problem for me. Not sure why you (Adam) are insisting it's a different bug...
Kae: Just because the same workaround happens to help, that doesn't mean it's the same bug. In one case, the BIOS is reporting that there is an IOMMU at physical address zero. It's relatively simple to detect that as soon as we see what the BIOS tells us, and abort the IOMMU setup. In the other case, the BIOS is reporting that there is an IOMMU at some other, more believable address -- but it's still lying, and there is no actual IOMMU at the location specified. What normally happens on a PC when you read from a non-existent physical location is that you get all 0xFFFFFFFF -- all ones. That one's a littler harder to check for, since you don't notice till you actually map the hardware and start talking to it. They're _similar_, but not actually the same. At least not as far as the kernel is concerned, although they _may_ actually be caused by the same underlying problem. Arguably they _are_ caused by the same underlying problems -- low quality BIOS, lack of QA, and a stupid design decision which relies on the BIOS vendors actually getting things right, rather than letting the kernel read the hardware configuration directly from the hardware. But there's little point in having a catch-all "the BIOS is crap and the idiots never test it" bug in Fedora bugzilla; it's better to catch the individual ways in which the broken situation manifests itself, and track them individually, surely? FWIW Chris has posted a patch in bug #524808 which should catch the 'all ones' bug too. Test build at http://koji.fedoraproject.org/koji/buildinfo?buildID=142281
This still shows the error in dmesg (and triggers kerneloops) though, like build 137, it doesn't need intel_iommu=off also, these three messages show up as my system boots... is this related? [drm:intel_dp_i2c_init] *ERROR* i2c_init DPDDC-B [drm:intel_dp_i2c_init] *ERROR* i2c_init DPDDC-C [drm:intel_dp_i2c_init] *ERROR* i2c_init DPDDC-D
Having said that, we _do_ cope with both of the above errors, by aborting the IOMMU setup and pretending it's not there. But there was a problem with the way we cope -- when we abort like that, the system _doesn't_ end up acting in the same was as if it never thought there was an IOMMU in the first place. And that means that it broke for people with RAM above 4GiB. We had a last-minute patch in the F12 release kernel which fixed that for people with RAM above 4GiB, for the 'DMAR at zero' case. Except that unfortunately (and embarrasingly) it actually broke things for people with _less_ RAM. The patch moved the location of the "DMAR at zero" sanity check, and then it didn't actually take effect for machines with less RAM -- so those machines started trying to use the non-existent IOMMU that the BIOS had advertises... and crashing. So bug #524808 is for RAM > 4GiB and was fixed in the release. This bug #533952 in for RAM < 4GiB and was _broken_ in the release, at the last minute. Sorry. Neither of them specifically address the 'all ones' problem, but it is a very similar fix (we need to detect it early, with a non-buggy patch that does actually take effect for low-RAM machines as well as high-RAM machines). So that's why Chris has done it and posted it in bug #524808. I don't think it's actually worth filing a separate bug now. In fact, even this one might as well be closed as a duplicate of bug #524808. No more test results from anything earlier than Chris's 2.6.31.6-144 kernel, please. ut the way we cope is wrong. That's bug #524808
(In reply to comment #49) > This still shows the error in dmesg (and triggers kerneloops) You mean it still tells you that your BIOS is broken? That's probably because your BIOS is still broken. Did you upgrade to a fixed BIOS? If not, you shouldn't be surprised that your BIOS is still broken. :) > though, like build 137, it doesn't need intel_iommu=off Good. Thanks for testing. > also, these three messages show up as my system boots... is this related? > > [drm:intel_dp_i2c_init] *ERROR* i2c_init DPDDC-B > [drm:intel_dp_i2c_init] *ERROR* i2c_init DPDDC-C > [drm:intel_dp_i2c_init] *ERROR* i2c_init DPDDC-D No, I believe those are harmless as it probes for which outputs have displays attached.
(In reply to comment #51) > (In reply to comment #49) > > This still shows the error in dmesg (and triggers kerneloops) > > You mean it still tells you that your BIOS is broken? > > That's probably because your BIOS is still broken. Did you upgrade to a fixed > BIOS? If not, you shouldn't be surprised that your BIOS is still broken. :) I realize that, but it's hard to update the BIOS with the tools provided by Acer (Windows programs... my guess is they wouldn't work in Wine) Anyone here know a better solution to this than sending my laptop to Acer? > > though, like build 137, it doesn't need intel_iommu=off > > Good. Thanks for testing. I do what I can to help. > > also, these three messages show up as my system boots... is this related? > > > > [drm:intel_dp_i2c_init] *ERROR* i2c_init DPDDC-B > > [drm:intel_dp_i2c_init] *ERROR* i2c_init DPDDC-C > > [drm:intel_dp_i2c_init] *ERROR* i2c_init DPDDC-D > > No, I believe those are harmless as it probes for which outputs have displays > attached. Then why are they showing up as errors when the situation is harmless? Shouldn't it be just another message? A Notice (I have no idea what types of messages can be in dmesg
(In reply to comment #52) > I realize that, but it's hard to update the BIOS with the tools provided by > Acer (Windows programs... my guess is they wouldn't work in Wine) Anyone here > know a better solution to this than sending my laptop to Acer? Install a FreeDos (http://www.freedos.org/) to an USB stick and boot from it. Some of the Acer provided BIOS versions also contain a DOS flasher. But BIOS 3302 still contains this error...
(In reply to comment #53) > Install a FreeDos (http://www.freedos.org/) to an USB stick and boot from it. > Some of the Acer provided BIOS versions also contain a DOS flasher. But BIOS > 3302 still contains this error... really? any real improvements on BIOS 3302? more configuration options perhaps? (sorry for the off-topic question)
I saw this on F12 ... and also on Rawhide 2.6.32rc5 and 7... now on kernel.org's git rc8. If it helps narrow things down, I'm running on an Asus p6t Deluxe v2 (with current bios); COre i7 920 and 16Gb ram. I didn't see this prior to F12. My kerneloops - if it helps: WARNING: at drivers/pci/intel-iommu.c:3774 init_dmars+0x32a/0x6ea() Hardware name: System Product Name Your BIOS is broken; DMA routed to ISOCH DMAR unit but no TLB space. BIOS vendor: American Megatrends Inc.; Ver: 0504 ; Product Version: System Version Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.32-rc8 #1 Call Trace: [<ffffffff81055319>] warn_slowpath_common+0x7c/0x94 [<ffffffff81055388>] warn_slowpath_fmt+0x41/0x43 [<ffffffff817b7be8>] init_dmars+0x32a/0x6ea [<ffffffff817b8213>] intel_iommu_init+0x26b/0x340 [<ffffffff81797965>] ? pci_iommu_init+0x0/0x32 [<ffffffff81797989>] pci_iommu_init+0x24/0x32 [<ffffffff8100a07d>] do_one_initcall+0x72/0x18a [<ffffffff817906d8>] kernel_init+0x181/0x1db [<ffffffff81012e0a>] child_rip+0xa/0x20 [<ffffffff8104b073>] ? finish_task_switch+0x50/0xa8 [<ffffffff81012741>] ? restore_args+0x0/0x30 [<ffffffff81790557>] ? kernel_init+0x0/0x1db [<ffffffff81012e00>] ? child_rip+0x0/0x20
Michael, do you actually have a problem to report, or are you just adding unrelated warnings about your BIOS to this bug report for fun? :)
Indeed. This bug at least has a workaround, which can be found in the comments above (which some people don't seem to be reading). At this point I think it's time to start harassing ASUS, HP, etc., about their crappy BIOSes.
I think we need hardware makers to see that they should use UEFI, since this BIOS hardly is a BIOS... it's a simulation... running as a compatibility layer on top of (U)EFI Can't we have Grub2 hook up on the UEFI and replace the BIOS?
David - I'm not 100% sure at this point. I'm seeing instability that may or may not be related to this... still tracking it down. Reading this ticket, I thought another data point might be helpful. Having done more reading, I can see how is probably an Asus issue, although I didn't have issues on F11 (no lockups or reported errors), but now have lockups and errors with only two kerneloops reported - this one, and a sky2 error that *seems* unrelated.
FWIW, I opened a ticket with Asus.
kae: thanks to david for the detailed explanation. To give a simpler explanation - the workaround detailed in this bug is a fairly broad hammer. It just disables the hardware IOMMU entirely. So, obviously, it'll work around most IOMMU-related bugs. That doesn't mean they're all the same bug, though. It's like saying that all bugs in the nouveau driver must be the same bug, because you can work around all of them by using the vesa driver instead. :) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #59) > David - I'm not 100% sure at this point. I'm seeing instability that may or may > not be related to this... still tracking it down. Reading this ticket, I > thought another data point might be helpful. Having done more reading, I can > see how is probably an Asus issue, although I didn't have issues on F11 (no > lockups or reported errors), but now have lockups and errors with only two > kerneloops reported - this one, and a sky2 error that *seems* unrelated. Please open a new bug for that. And if it goes away when you boot with 'iommu=off' or 'iommu=soft', please Cc me.
Dear David, In my opinion this bios error problem is more serious than look. I think Fedora urgently should release a minor fix release. Also as far as my experiences with Fedora V 12 unfortunately I can say it is not a stable enough. I tried to install Fedora 12 many times into both of my HP laptop, every time faced with the different kernel problems. I sometimes could submit these error messages but sometimes I could not. It is really hard to say but V12 is completely disappointment. Best Regards, Dogan YILMAZ
Dogan, a fix has been released to updates-testing already; please test it: http://admin.fedoraproject.org/updates/kernel-2.6.31.6-145.fc12 I think the tone of your response is a little harsh. Remember, you've bought a cheap, broken laptop from a company which is reported to be the world's least reliable laptop manufacturer: http://www.electronista.com/articles/09/11/17/reliability.study.has.apple.4th.place/ We try very hard to make the Fedora kernel work properly on this kind of cheap, broken hardware -- and the 2.6.31.6-145 kernel should work around all the currently-known bugs. We've not rushed that kernel out; we're putting it through proper testing in the updates-testing repository. Our previous attempt at a quick fix for this brain damage was rushed, and just shifted the problem from machines with >4GiB to machines with <4GiB, as described in comment #50. So I'm sure you understand why we want to be a little more methodical with the new update. Please, test the update and let us know if it doesn't fix everything for you. And report the broken laptop to the place you purchased it. If it was mine, I'd probably return it and ask for my money back. But you should at least demand a fixed BIOS which doesn't require these workarounds. One which has seen at least some _basic_ testing on their part, perhaps?
I have one more question for you, David. I understood that for me this bug needs fixing in the BIOS, not the Linux kernel. The kernel now doesn't panic anymore (since the 137 version AFAIK) though it does still report the DMAR mistake in the dmesg. Now my question: Does this negatively change the behaviour of my system? Can VT-d work properly with the BIOS not reporting the IOMMU-location correctly for example? I won't blame you for not knowing this.
When you see that error, we've aborted the IOMMU setup and it won't work. I believe that it should only happen when VT-d is disabled in the BIOS though -- if you enable it in the BIOS, then it should work. Technically, we _ought_ to be able to find the real location of the IOMMU by querying the hardware itself (it's in PCI config space somewhere, usually). But the current "design" stupidly involves trusting the BIOS to tell us where it is. I'm working on getting permission to probe for it directly, at least as a sanity check. That involves getting permission because the details of _which_ parts of PCI config space are unfortunately in the wrong part of the chipset spec -- the private part. And there are some write-once registers which mean that if it's actually disabled, the kernel wouldn't be able to enable it.
I am seeing almost the exact same error as Michael Hampton. I have seen this error on ASUS firmware 707 and on 904 (i tried upgrading after reading this thread). Is there anything I can do to help get this fixed? Hardware: ASUS P6T INTEL i7 920 NVIDIA graphics ------------[ cut here ]------------ WARNING: at drivers/pci/intel-iommu.c:3724 init_dmars+0x331/0x6f1() (Not tainted) Hardware name: System Product Name Your BIOS is broken; DMA routed to ISOCH DMAR unit but no TLB space. BIOS vendor: American Megatrends Inc.; Ver: 0904 ; Product Version: System Version Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.31.6-145.fc12.x86_64 #1 Call Trace: [<ffffffff810516f4>] warn_slowpath_common+0x84/0x9c [<ffffffff81051763>] warn_slowpath_fmt+0x41/0x43 [<ffffffff8173d461>] init_dmars+0x331/0x6f1 [<ffffffff8173da8c>] intel_iommu_init+0x26b/0x32a [<ffffffff8171bb41>] ? pci_iommu_init+0x0/0x21 [<ffffffff8171bb4f>] pci_iommu_init+0xe/0x21 [<ffffffff8100a069>] do_one_initcall+0x5e/0x162 [<ffffffff81714750>] kernel_init+0x219/0x273 [<ffffffff81012daa>] child_rip+0xa/0x20 [<ffffffff81714537>] ? kernel_init+0x0/0x273 [<ffffffff81012da0>] ? child_rip+0x0/0x20 (In reply to comment #24) > I'm back and I've been playing around with different BIOSes, something that > ASUS seems to have a lot of trouble with. Here are my results. > > After reading bug 524808 I'm going to do some more testing with VT-d disabled > (it was enabled for all tests here). > > ASUS P6T6 WS Revolution motherboard; BIOSes tested were 0311 and 0507 (latest) > > 0311 BIOS with -127 kernel requires intel_iommu=off to boot. Panic without > option. No kernel oops is logged. > 0311 BIOS with -137 kernel requires intel_iommu=off to boot. Panic without > option. No kernel oops is logged. > 0507 BIOS with -127 kernel requires intel_iommu=off to boot. Panic without > option. No kernel oops is logged. > 0507 BIOS with -137 kernel does not require option to boot. A kernel oops is > logged: > > ------------[ cut here ]------------ > WARNING: at drivers/pci/intel-iommu.c:3724 init_dmars+0x331/0x6f1() (Not > tainted) > Hardware name: System Product Name > Your BIOS is broken; DMA routed to ISOCH DMAR unit but no TLB space. > BIOS vendor: American Megatrends Inc.; Ver: 0507 ; Product Version: System > Version > Modules linked in: > Pid: 1, comm: swapper Not tainted 2.6.31.5-127.fc12.x86_64 #1 > Call Trace: > [<ffffffff81051694>] warn_slowpath_common+0x84/0x9c > [<ffffffff81051703>] warn_slowpath_fmt+0x41/0x43 > [<ffffffff8173d345>] init_dmars+0x331/0x6f1 > [<ffffffff8173d970>] intel_iommu_init+0x26b/0x32a > [<ffffffff8171bb41>] ? pci_iommu_init+0x0/0x21 > [<ffffffff8171bb4f>] pci_iommu_init+0xe/0x21 > [<ffffffff8100a069>] do_one_initcall+0x5e/0x162 > [<ffffffff81714750>] kernel_init+0x219/0x273 > [<ffffffff81012daa>] child_rip+0xa/0x20 > [<ffffffff81714537>] ? kernel_init+0x0/0x273 > [<ffffffff81012da0>] ? child_rip+0x0/0x20 > ---[ end trace f17e946d22a56015 ]---
I have 3 gb of ram, forgot to mention that... (In reply to comment #67)
Austin, are you actually encountering any problems with the latest kernel? If it's just telling you that your BIOS is broken, that's expected. That means it detected the problem and is working around it. If you really want to get rid of that warning then you need to contact your system or motherboard vendor and demand a fixed BIOS -- and maybe suggest that they actually do some testing on it this time.
No, Im not actually encountering any problems, I just keep getting the warning every time I boot. Thanks so much for the help, I just didn't know if there was something ugly going on that I didn't know about or not.
I believe we now detect and work around this BIOS brokenness correctly; closing.
@David: When this patch will be available? This bug prevented me from installing fedora on my laptop. Does it mean that I will be able to install it now?
Tamás, can't you boot with 'iommu=off' to get the install to work? Then you can update to the current kernel and you shouldn't need 'iommu=off' any more. You _could_ also install from a fresh spin of F-12+updates, like the Unity respins, but there's no real need for that.
No, unfortunately iommu=off didn't work. It gets a little further with booting, but it crashes again. I will have some free time in the weekend, and then I'll look into it. Thanks.
That sounds like something entirely different then.
Without the ioummu=off parameter, the error message is the same: "Kernel panic - not syncing: DMAR hardware is malfunctioning". And it's an HP 6730s. So I think it's related at least.
Try using "intel_iommu=off"
I remember trying intel_iommu, but that didn't work either. However, I tried iommu=off again, and now I was able to run the installer! The I rebooted, added iommu=off to kernel line, and went on with the booting. After the gnome login screen, it froze every time. Then I changed to a text terminal, and updated the system. Now it works perfectly. Can I provide any more information with the bug? It did work this time, but I didn't change anything in the hardware. -- A happy F12 user :)
Created attachment 385546 [details] DMAR.dsl
Cyrus: er, was there any particular reason for that attachment? It shows you have a broken BIOS: [030h 0048 2] Subtable Type : 0000 <Hardware Unit Definition> [032h 0050 2] Length : 0010 [034h 0052 1] Flags : 01 [035h 0053 1] Reserved : 00 [036h 0054 2] PCI Segment Number : 0000 [038h 0056 8] Register Base Address : 0000000000000000 The kernel should detect this, complain loudly about how stupid your BIOS engineers were, and continue with the IOMMU disabled. Is that not what happens? Is there something you're trying to tell us?
Hi there, My machine boots okay, and services all seem to run... BUT on the primary display device on the box itself I do see constant dumps about five times a minute. I'm using Fedora 12 on an HP Proliant DL380 G3 with twin Xeon 3.2GHz processors, 4GB RAM and the latest available bios firmware (P29 - 09/15/2004) I ran a memory check and the ram seems fine - I have 1GB sticks in DIMM01 and 02, and 512MB in 03-06 for a total of 4GB. I pulled the four 512MB sticks and retried, same result with 2GB I have run all available Yum updates but feel very uncomfortable making this web server my production machine until I can stem this flow of messages. I cleared my /var/log/messages file which had gotten to 6MB after less than a day switched on and saved the last little chunk that formed - here's the last dump in that file: Feb 12 10:03:37 mta kernel: ------------[ cut here ]------------ Feb 12 10:03:37 mta kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0x96/0xfe() (Tainted: G W ) Feb 12 10:03:37 mta kernel: Hardware name: ProLiant DL380 G3 Feb 12 10:03:37 mta kernel: Modules linked in: sunrpc ipv6 p4_clockmod dm_multipath scb2_flash mtd chipreg map_funcs i2c_piix4 tg3 i2c_core cpqphp hpilo hpwdt pata_acpi ata_generic cciss pata_serverworks [last unloaded: microcode] Feb 12 10:03:37 mta kernel: Pid: 44, comm: pdflush Tainted: G W 2.6.31.12-174.2.3.fc12.i686.PAE #1 Feb 12 10:03:37 mta kernel: Call Trace: Feb 12 10:03:37 mta kernel: [<c043db4b>] warn_slowpath_common+0x70/0x87 Feb 12 10:03:37 mta kernel: [<c04faafd>] ? dquot_claim_space+0x96/0xfe Feb 12 10:03:37 mta kernel: [<c043db74>] warn_slowpath_null+0x12/0x15 Feb 12 10:03:37 mta kernel: [<c04faafd>] dquot_claim_space+0x96/0xfe Feb 12 10:03:37 mta kernel: [<c0541dfe>] ext4_mb_mark_diskspace_used+0x273/0x311 Feb 12 10:03:37 mta kernel: [<c053fc6e>] ? ext4_mb_use_preallocated+0x185/0x1a9 Feb 12 10:03:37 mta kernel: [<c0544d9c>] ext4_mb_new_blocks+0x1e6/0x41a Feb 12 10:03:37 mta kernel: [<c053df30>] ext4_ext_get_blocks+0xf57/0x1168 Feb 12 10:03:37 mta kernel: [<c058f6d0>] ? generic_make_request+0x214/0x261 Feb 12 10:03:37 mta kernel: [<c0524a03>] ext4_get_blocks+0x125/0x2c2 Feb 12 10:03:37 mta kernel: [<c0524cce>] mpage_da_map_blocks+0x9b/0x6a1 Feb 12 10:03:37 mta kernel: [<c04a0b4b>] ? write_cache_pages+0x124/0x2b5 Feb 12 10:03:37 mta kernel: [<c05259b5>] ? __mpage_da_writepage+0x0/0x15b Feb 12 10:03:37 mta kernel: [<c05505a4>] ? jbd2_journal_start+0x53/0xbb Feb 12 10:03:37 mta kernel: [<c05505df>] ? jbd2_journal_start+0x8e/0xbb Feb 12 10:03:37 mta kernel: [<c0525733>] ext4_da_writepages+0x45f/0x623 Feb 12 10:03:37 mta kernel: [<c059ea48>] ? cpumask_next_and+0x23/0x2f Feb 12 10:03:37 mta kernel: [<c04343be>] ? find_busiest_group+0x255/0x55d Feb 12 10:03:37 mta kernel: [<c04a0d29>] do_writepages+0x25/0x39 Feb 12 10:03:37 mta kernel: [<c04df1f6>] writeback_single_inode+0x125/0x21e Feb 12 10:03:37 mta kernel: [<c06c1458>] ? dm_any_congested+0x4c/0x57 Feb 12 10:03:37 mta kernel: [<c04df663>] generic_sync_sb_inodes+0x207/0x314 Feb 12 10:03:37 mta kernel: [<c04df865>] writeback_inodes+0x7e/0xbe Feb 12 10:03:37 mta kernel: [<c04a0e68>] wb_kupdate+0x92/0xf3 Feb 12 10:03:37 mta kernel: [<c04a1995>] ? pdflush+0x0/0x1db Feb 12 10:03:37 mta kernel: [<c04a1aa5>] pdflush+0x110/0x1db Feb 12 10:03:37 mta kernel: [<c04a0dd6>] ? wb_kupdate+0x0/0xf3 Feb 12 10:03:37 mta kernel: [<c0450b0f>] kthread+0x70/0x75 Feb 12 10:03:37 mta kernel: [<c0450a9f>] ? kthread+0x0/0x75 Feb 12 10:03:37 mta kernel: [<c0409c07>] kernel_thread_helper+0x7/0x10 Feb 12 10:03:37 mta kernel: ---[ end trace ad0a028d9e603e8d ]--- Feb 12 10:03:37 mta kernel: ------------[ cut here ]------------ Can anyone shed any light on this please?
@Martin Francis, your issue does not appear related to this bug. I would suggest you open a new report or make a post on the Fedora forum.
@Michael Hampton, Sorry to be such a newbie, but I don't even know what it is I'm looking at - what might you suggest as a title for the new bug?