This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 533952 - DMAR: kernel panic with 2.6.31.5-127.fc12.i686
DMAR: kernel panic with 2.6.31.5-127.fc12.i686
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: David Woodhouse
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs, Triaged
: 538552 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-09 16:29 EST by Thomas Meyer
Modified: 2010-08-11 11:05 EDT (History)
23 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-01-13 12:15:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
kernel dmesg 2.6.31.6-136.hptest.fc12.x86_64 (42.72 KB, text/plain)
2009-11-17 21:15 EST, Thomas Davis
no flags Details
BIOS DMAR.dsl (2.61 KB, text/x-dsl)
2009-11-17 21:19 EST, Thomas Davis
no flags Details
dmesg output with test kernel (40.43 KB, text/plain)
2009-11-18 01:18 EST, Rajaseelan
no flags Details
kernel dmesg 2.6.31.6-137.fc12.x86_64 (42.38 KB, text/plain)
2009-11-18 13:09 EST, Thomas Davis
no flags Details
DMAR.dsl (2.61 KB, application/octet-stream)
2010-01-19 17:26 EST, Cyrus
no flags Details

  None (edit)
Description Thomas Meyer 2009-11-09 16:29:43 EST
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?
Comment 1 Ben Konrath 2009-11-10 12:59:29 EST
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.
Comment 2 Thomas Meyer 2009-11-11 16:59:26 EST
Workaround seems to be to add "intel_iommu=off" to the boot commandline.
Comment 3 Bug Zapper 2009-11-16 10:22:44 EST
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
Comment 4 kae verens 2009-11-17 12:27:44 EST
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
Comment 5 kae verens 2009-11-17 12:28:30 EST
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.
Comment 6 David Woodhouse 2009-11-17 15:39:30 EST
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)
Comment 7 Rajaseelan 2009-11-17 17:22:33 EST
Same thing here. Darn Insyde BIOS !@#$%^, will add information ASAP
Comment 8 David Woodhouse 2009-11-17 17:36:09 EST
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.
Comment 9 Thomas Davis 2009-11-17 21:15:20 EST
Created attachment 369998 [details]
kernel dmesg 2.6.31.6-136.hptest.fc12.x86_64

Kernel dmesg
Comment 10 Thomas Davis 2009-11-17 21:19:14 EST
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
Comment 11 Rajaseelan 2009-11-17 23:33:18 EST
@tdavis

THats the same Machine & BIOS I'm using. Trying to download F12 x86_64 to test the kernel
Comment 12 Rajaseelan 2009-11-18 01:18:01 EST
Created attachment 370019 [details]
dmesg output with test kernel

dmesg output with test kernel
Comment 13 Thomas Davis 2009-11-18 01:28:28 EST
(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..
Comment 14 Ben Konrath 2009-11-18 01:54:10 EST
(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.
Comment 15 David Woodhouse 2009-11-18 05:29:55 EST
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?
Comment 16 Thomas Davis 2009-11-18 13:07:46 EST
(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..
Comment 17 Thomas Davis 2009-11-18 13:09:27 EST
Created attachment 370148 [details]
kernel dmesg 2.6.31.6-137.fc12.x86_64

Running with no intel_iommu cmdline option.
Comment 18 Athmane Madjoudj 2009-11-18 15:58:30 EST
*** Bug 538552 has been marked as a duplicate of this bug. ***
Comment 19 Michael Hampton 2009-11-18 17:30:32 EST
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
Comment 20 Adam Williamson 2009-11-18 18:30:58 EST
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
Comment 21 David Woodhouse 2009-11-18 18:48:48 EST
I can't see how that could be the case.
Comment 22 Adam Williamson 2009-11-18 19:03:06 EST
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
Comment 23 Adam Williamson 2009-11-18 19:06:31 EST
duh...524808, of course.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 24 Michael Hampton 2009-11-18 19:59:27 EST
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 ]---
Comment 25 David Woodhouse 2009-11-18 20:51:29 EST
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.
Comment 26 kiro_jianwei 2009-11-19 00:25:08 EST
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
Comment 27 Michael Hampton 2009-11-19 00:31:32 EST
What happened when you tried the workaround described in comment #2?
Comment 28 kiro_jianwei 2009-11-19 00:46:25 EST
(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?
Comment 29 Adam Williamson 2009-11-19 01:05:54 EST
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
Comment 30 Adam Williamson 2009-11-19 01:07:50 EST
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
Comment 31 Michael Hampton 2009-11-19 01:08:05 EST
(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.
Comment 32 kiro_jianwei 2009-11-19 03:27:02 EST
(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??
Comment 33 Athmane Madjoudj 2009-11-19 03:37:48 EST
> 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
Comment 34 Athmane Madjoudj 2009-11-19 03:53:11 EST
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 ]---
Comment 35 David Woodhouse 2009-11-19 04:03:06 EST
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.
Comment 36 kiro_jianwei 2009-11-19 07:23:53 EST
(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?
Comment 37 Athmane Madjoudj 2009-11-19 08:38:46 EST
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
Comment 38 kiro_jianwei 2009-11-19 09:10:42 EST
(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.
Comment 39 Adam Williamson 2009-11-19 14:54:08 EST
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
Comment 40 Adam Williamson 2009-11-19 14:54:42 EST
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
Comment 41 'j 2009-11-21 06:12:12 EST
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.
Comment 42 Adam Williamson 2009-11-21 11:30:49 EST
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
Comment 43 kiro_jianwei 2009-11-21 12:15:50 EST
Same.. I also got the same error when I use the live CD image. From comment 41
My laptop is HP dv4
Comment 44 Adam Williamson 2009-11-21 12:31:16 EST
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
Comment 45 Luit van Drongelen 2009-11-21 16:52:29 EST
(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)
Comment 46 'j 2009-11-22 03:04:19 EST
thanks for your help, i'm filing a new bug.
Comment 47 kae verens 2009-11-22 04:59:15 EST
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...
Comment 48 David Woodhouse 2009-11-22 05:39:01 EST
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
Comment 49 Luit van Drongelen 2009-11-22 05:58:50 EST
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
Comment 50 David Woodhouse 2009-11-22 06:19:28 EST
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
Comment 51 David Woodhouse 2009-11-22 06:21:16 EST
(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.
Comment 52 Luit van Drongelen 2009-11-22 06:32:23 EST
(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
Comment 53 Thomas Meyer 2009-11-22 08:41:35 EST
(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...
Comment 54 Luit van Drongelen 2009-11-22 10:33:36 EST
(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)
Comment 55 Michael Breuer 2009-11-22 16:11:23 EST
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
Comment 56 David Woodhouse 2009-11-22 17:23:02 EST
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? :)
Comment 57 Michael Hampton 2009-11-22 17:29:14 EST
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.
Comment 58 Luit van Drongelen 2009-11-22 18:07:59 EST
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?
Comment 59 Michael Breuer 2009-11-22 19:50:15 EST
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.
Comment 60 Michael Breuer 2009-11-22 20:13:14 EST
FWIW, I opened a ticket with Asus.
Comment 61 Adam Williamson 2009-11-23 15:00:00 EST
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
Comment 62 David Woodhouse 2009-11-23 17:36:36 EST
(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.
Comment 63 Dogan YILMAZ 2009-11-24 03:49:17 EST
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
Comment 64 David Woodhouse 2009-11-24 04:38:47 EST
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?
Comment 65 Luit van Drongelen 2009-11-24 05:33:43 EST
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.
Comment 66 David Woodhouse 2009-11-24 05:49:11 EST
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.
Comment 67 Austin Page 2009-12-03 14:07:43 EST
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 ]---
Comment 68 Austin Page 2009-12-03 14:11:50 EST
I have 3 gb of ram, forgot to mention that...

(In reply to comment #67)
Comment 69 David Woodhouse 2009-12-04 02:18:59 EST
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.
Comment 70 Austin Page 2009-12-04 11:56:31 EST
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.
Comment 71 David Woodhouse 2010-01-13 12:15:24 EST
I believe we now detect and work around this BIOS brokenness correctly; closing.
Comment 72 Tamás Szelei 2010-01-13 12:23:29 EST
@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?
Comment 73 David Woodhouse 2010-01-13 13:27:38 EST
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.
Comment 74 Tamás Szelei 2010-01-13 13:47:18 EST
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.
Comment 75 David Woodhouse 2010-01-13 13:58:34 EST
That sounds like something entirely different then.
Comment 76 Tamás Szelei 2010-01-13 14:09:45 EST
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.
Comment 77 Thomas Davis 2010-01-13 14:33:58 EST
Try using "intel_iommu=off"
Comment 78 Tamás Szelei 2010-01-16 16:30:43 EST
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 :)
Comment 79 Cyrus 2010-01-19 17:26:45 EST
Created attachment 385546 [details]
DMAR.dsl
Comment 80 David Woodhouse 2010-01-19 20:31:55 EST
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?
Comment 81 Martin Francis 2010-02-12 10:50:11 EST
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?
Comment 82 Michael Hampton 2010-02-12 10:58:44 EST
@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.
Comment 83 Martin Francis 2010-02-12 11:07:18 EST
@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?

Note You need to log in before you can comment on or make changes to this bug.