On Sun, Feb 28, 2010 at 04:47:21PM -0700, Nadolski, Ed wrote:
> > -----Original Message-----
> On 02/25/2010 02:18 PM, Nadolski, Ed wrote:
> > I'm running Fedora 12 (kernel 2.6.31.5-127.fc12.x86_64) on a Dell T7500
> > Xeon with VT-x and VT-d. After building xen-unstable and rebooting, the
> > dom0 Linux hangs a few seconds after it gets control from Xen, and I have
> > to power-cycle to recover. Here are the last messages before it hangs:
> >
> > [ 2.766882] loop: module loaded
> > [ 2.767736] input: Macintosh mouse button emulation as
> > /devices/virtual/input/input2
> > [ 2.769396] xen_set_ioapic_routing: irq 20 gsi 20 vector 20 ioapic 0 pin
> > 20 triggering 1 polarity 1
> > [ 2.770342] achi 0000:00:1f.2: PCI INT C -> GSI 20 (level, low) -> IRQ
> > 20
> > [ 2.771158] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps
> > 0x27 impl SATA mode
> > [ 2.772078] ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo pio ems
> > <<hangs at this point>>
>
>
>
> I've added a bunch of trace prints. With serial ports enabled for trace
> capture, the hang actually occurs earlier than the ahci code above. It now
> occurs during the serial8250_config_port() function in the 8250/16650 serial
> driver initialization. There is a call to probe_irq_on(), which calls
> msleep(20), but the msleep() never returns. (see below)
>
> If I hit the power button on the front panel, it generates an interrupt that
> forces the msleep() to return. Also, if I replace the msleep(20) with
> mdelay(20), the code does not hang at that point. (In either case, the code
> does hang again a short while later.)
>
> I'm not too familiar with kernel internals - what could cause the msleep()
> not to return? Possibly an interrupt gets missed, or is not getting unmasked?
I think you are hot on the trail. Try hitting 'i' (or maybe it is 'I')
and see what Xen prints out for the IRQ mapping. Earlier on you
mentioned that you saw: "Xen: Cannot share IRQ0 with guest." which is a
bit strange, considering you are booting Dom0. IRQ0 is usually the
timer, but it looks as if the serial port is on interrupt 0? It
shouldn't be - try adding some more printk's and find out what IRQ it
thinks it is.
Also try to boot the kernel without Xen and see what IRQ the serial port
driver uses then.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home