Clone of F-7 bug caused by Firewire modules not being supported under the Xen 
kernel.

+++ This bug was initially created as a clone of Bug #302471 +++

Description of problem:
I am unable to boot a xen kernel (either 2.6.20-2925.9.fc7xen or
2.6.20-2931.fc7xen) on my quad core Intel x86_64 box.  When I try the boot 
fails
with a modprobe error.  Unfortunately, I do not know how to enable logging to
record this for debugging purposes (boot.log is always empty).

Version-Release number of selected component (if applicable):
xen-3.1.0-2.fc7


How reproducible:
Always occurs.


Steps to Reproduce:
1.  Install the x86 FC7 image on the x86_64 box.
2.  Include virtualization in the installation
3.  Attempt to boot the xen image.
  
Actual results:
Boot fails with a modprobe error.


Expected results:
Xen enabled kernel should boot.  Note that it does boot if I install x86_64 
fc7
instead.



Additional info:
I don't know how to record this boot issue.  /var/log/boot.log is always 
empty.

-- Additional comment from rjones@redhat.com on 2007-09-24 06:56 EST --
Please boot, adding 'noreboot' to the Xen command line, then write down
the error or take a snapshot.

-- Additional comment from moose@quadruped.com on 2007-09-25 21:06 EST --
Created an attachment (id=206301)
dmesg output from xen boot

When I added the noreboot, the system eventually booted.  Here is the dmesg
log.  When the boot failed, it stopped after displaying line 568 (floppy0: no
floppy controllers found) and displayed a sys/modprobe error before that line.

-- Additional comment from moose@quadruped.com on 2007-09-25 21:30 EST --
Created an attachment (id=206311)
messages log file from fc7xen boot

Here is a bit more.  I removed the noreboots and the boot hung in the same
place.	I discovered that if I press the Print Screen / SysRq key, the boot
will continue.	This attachment contains the messages log that contains more
information than the previous dmesg log.  This contains a modprobe error at 
the
place that I see it when the boot hangs.

-- Additional comment from ehabkost@redhat.com on 2007-09-26 13:19 EST --
It is being caused by the Firewire stack trying to use DMA in a way not 
currently supported by the Xen kernel.

The firewire stack was supposed to be disabled on the Xen kernel. You can work 
around the problem by removing the firewire modules 
under /lib/modules/2.6.20-2931.fc7xen/kernel/firewire.