[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Fedora-xen] [BUG] dmidecode in DomU throws thousands of xen printk's



Hi All

One more bug... in a seperate email so they don't get confused.

System is kernel-xen-2.6.17-1.2157_FC5 on a 2p opteron (older non-hardware-virt). This happens when I try to run the 'dmidecode' tool from within a non-privileged guest. The guest is running the same kernel as above. One other note is that the console on this system is serial, ttyS0 at 9600bps... which may have something to do with the CPU lockup bugs below.

I basically get thousands of the following printk messages, starting with:

(XEN) DOM4: (file=mm.c, line=578) Non-privileged attempt to map I/O space 000000f0

and counting up and ending with:

(XEN) DOM4: (file=mm.c, line=578) Non-privileged attempt to map I/O space 000000ff

Then, some of the time, the kernel throws a spinlock timer at the end of all of these printks:

Timer ISR/1: Time went backwards: delta=-46186990 delta_cpu=-42186990 shadow=2112479126776 off=466807746 processed=2112992120678 cpu_processed=2112988120678
BUG: spinlock lockup on CPU#0, swapper/0, c06e9284 (Not tainted)
<c04e74b0> __spin_lock_debug+0x7b/0x85 <c04e7514> _raw_spin_lock+0x5a/0x69
 <c061eedb> _spin_lock+0x6/0x8  <c0407d80> timer_interrupt+0x40/0x563
 <c0434533> ktime_get_ts+0x4b/0x51  <c0434484> ktime_get+0x10/0x3a
 <c0442fe3> handle_IRQ_event+0x40/0x82  <c04430b0> __do_IRQ+0x8b/0xdf
 <c0406336> do_IRQ+0x1a/0x25  <c054c937> evtchn_do_upcall+0x84/0xb8
 <c0404c71> hypervisor_callback+0x3d/0x48  <c04087da> safe_halt+0x1a/0x2f
 <c0402b98> kernel_thread_helper+0x0/0xb  <c04028a9> xen_idle+0x45/0x4d
 <c0402945> cpu_idle+0x94/0xad  <c07047cf> start_kernel+0x1c1/0x1c5
 0: 2112992120678
 1: 2112988120678
BUG: soft lockup detected on CPU#1!
<c0442e2d> softlockup_tick+0x9a/0xab <c040825d> timer_interrupt+0x51d/0x563
 <c0442fe3> handle_IRQ_event+0x40/0x82  <c04430b0> __do_IRQ+0x8b/0xdf
 <c0406336> do_IRQ+0x1a/0x25  <c054c937> evtchn_do_upcall+0x84/0xb8
<c0404c71> hypervisor_callback+0x3d/0x48 <c054c8b1> force_evtchn_callback+0xa/0xc
 <c04248cf> __do_softirq+0x67/0xee  <c0424995> do_softirq+0x3f/0x63
 <c040633b> do_IRQ+0x1f/0x25  <c054c937> evtchn_do_upcall+0x84/0xb8
 <c0404c71> hypervisor_callback+0x3d/0x48  <c04087da> safe_halt+0x1a/0x2f
 <c04028a9> xen_idle+0x45/0x4d  <c0402945> cpu_idle+0x94/0xad
BUG: soft lockup detected on CPU#0!
<c0442e2d> softlockup_tick+0x9a/0xab <c040825d> timer_interrupt+0x51d/0x563
 <c0434533> ktime_get_ts+0x4b/0x51  <c0442fe3> handle_IRQ_event+0x40/0x82
 <c04430b0> __do_IRQ+0x8b/0xdf  <c0406336> do_IRQ+0x1a/0x25
<c054c937> evtchn_do_upcall+0x84/0xb8 <c0404c71> hypervisor_callback+0x3d/0x48
 <c04087da> safe_halt+0x1a/0x2f  <c0402b98> kernel_thread_helper+0x0/0xb
 <c04028a9> xen_idle+0x45/0x4d  <c0402945> cpu_idle+0x94/0xad
 <c07047cf> start_kernel+0x1c1/0x1c5

Once, I even had the storage controller (3ware 9500) barf on me due to an I/O timeout that it couldn't recover from. I didn't have my console capture setup for that one, unfortunately.

I assume that this is the smbios hardware address space that dmidecode is trying to access via the guest kernel. I'm also guessing that the printk has interrupts disabled or something similarly funky, so the flood of them causes the CPU lockup messages as well as probably the I/O problems.

I saw some patches on the xen-devel list about adding real smbios data to the HVM virtual hosts, but it seemed to be very HVM-specific code, and I'm running paravirts. The thread from that is here:
http://lists.xensource.com/archives/html/xen-devel/2006-07/msg00416.html

I'd be happy if dmidecode just returned nothing but the console didn't spew messages like this. As you can imagine, the whole system (all virts) is unuseable while this is happening, and it runs for minutes at a time.

Thanks again

-Matt


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]