|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Time stopped
Ian,
I tried to reproduce with maxcpus=1 two or three times yesterday, and
the problem did not happen. It is not definitive, though, because xm-
test sometimes does run. But this morning, it hit the bug the first time
through, in the regular test (w/o the maxcpus parm).
On Thu, 2005-10-13 at 20:21 +0100, Ian Pratt wrote:
>
> > x335b:~ # cat /proc/interrupts
>
> You'll need to do this multiple times e.g. 10 seconds appart for us to
> figure out the rate.
>
x335b:~ # cat /proc/interrupts
CPU0
1: 10 Phys-irq i8042
5: 0 Phys-irq acpi
11: 0 Phys-irq ohci_hcd:usb1
12: 110 Phys-irq i8042
15: 28 Phys-irq ide1
22: 9800 Phys-irq ioc0
24: 38166 Phys-irq peth0
256: 8489111 Dynamic-irq timer0
257: 0 Dynamic-irq console
258: 0 Dynamic-irq net-be-dbg
259: 13709 Dynamic-irq xenbus
NMI: 0
LOC: 0
ERR: 0
MIS: 0
x335b:~ # cat /proc/interrupts
CPU0
1: 10 Phys-irq i8042
5: 0 Phys-irq acpi
11: 0 Phys-irq ohci_hcd:usb1
12: 110 Phys-irq i8042
15: 28 Phys-irq ide1
22: 9800 Phys-irq ioc0
24: 38199 Phys-irq peth0
256: 8489111 Dynamic-irq timer0
257: 0 Dynamic-irq console
258: 0 Dynamic-irq net-be-dbg
259: 13709 Dynamic-irq xenbus
NMI: 0
LOC: 0
ERR: 0
MIS: 0
x335b:~ # cat /proc/interrupts
CPU0
1: 10 Phys-irq i8042
5: 0 Phys-irq acpi
11: 0 Phys-irq ohci_hcd:usb1
12: 110 Phys-irq i8042
15: 28 Phys-irq ide1
22: 9800 Phys-irq ioc0
24: 38238 Phys-irq peth0
256: 8489111 Dynamic-irq timer0
257: 0 Dynamic-irq console
258: 0 Dynamic-irq net-be-dbg
259: 13709 Dynamic-irq xenbus
NMI: 0
LOC: 0
ERR: 0
MIS: 0
x335b:~ # cat /proc/interrupts
CPU0
1: 10 Phys-irq i8042
5: 0 Phys-irq acpi
11: 0 Phys-irq ohci_hcd:usb1
12: 110 Phys-irq i8042
15: 28 Phys-irq ide1
22: 9800 Phys-irq ioc0
24: 38272 Phys-irq peth0
256: 8489111 Dynamic-irq timer0
257: 0 Dynamic-irq console
258: 0 Dynamic-irq net-be-dbg
259: 13709 Dynamic-irq xenbus
NMI: 0
LOC: 0
ERR: 0
MIS: 0
----
x335b:~ # cat /proc/interrupts
CPU0
1: 10 Phys-irq i8042
5: 0 Phys-irq acpi
11: 0 Phys-irq ohci_hcd:usb1
12: 110 Phys-irq i8042
15: 28 Phys-irq ide1
22: 9800 Phys-irq ioc0
24: 38407 Phys-irq peth0
256: 8582512 Dynamic-irq timer0
257: 0 Dynamic-irq console
258: 0 Dynamic-irq net-be-dbg
259: 13709 Dynamic-irq xenbus
NMI: 0
LOC: 0
ERR: 0
MIS: 0
x335b:~ # cat /proc/interrupts
CPU0
1: 10 Phys-irq i8042
5: 0 Phys-irq acpi
11: 0 Phys-irq ohci_hcd:usb1
12: 110 Phys-irq i8042
15: 28 Phys-irq ide1
22: 9800 Phys-irq ioc0
24: 38450 Phys-irq peth0
256: 8582513 Dynamic-irq timer0
257: 0 Dynamic-irq console
258: 0 Dynamic-irq net-be-dbg
259: 13709 Dynamic-irq xenbus
NMI: 0
LOC: 0
ERR: 0
MIS: 0
x335b:~ # cat /proc/interrupts
CPU0
1: 10 Phys-irq i8042
5: 0 Phys-irq acpi
11: 0 Phys-irq ohci_hcd:usb1
12: 110 Phys-irq i8042
15: 28 Phys-irq ide1
22: 9800 Phys-irq ioc0
24: 38482 Phys-irq peth0
256: 8675691 Dynamic-irq timer0
257: 0 Dynamic-irq console
258: 0 Dynamic-irq net-be-dbg
259: 13709 Dynamic-irq xenbus
NMI: 0
LOC: 0
ERR: 0
MIS: 0
>
> > >
> > > If you run something in the background that burns CPU does
> > it make a
> > > difference?
> > I started LTP on dom0 ( and can see console outpu) and it
> > makes no difference.
>
> I think a "while true; do true; done" might be more convincing, but LTP
> is probably good enough.
Did this. Time still static. Other sessions become unresponsive while this runs.
>
> > > In this case, what does xm list show as regards the CPU
> > time consumed
> > > by the domains?
> > x335b:/tmp/ltp-full-20050804 # date
> > Thu Oct 13 13:47:59 CDT 2005
> > x335b:/tmp/ltp-full-20050804 # xm list
> > Name ID Mem(MiB) CPU VCPUs State Time(s)
> > Domain-0 0 495 - 4 r----- 96.5
> > 11_create_0 73 16 3 1 -b---- 0.3
> > x335b:/tmp/ltp-full-20050804 # xm list
> > Name ID Mem(MiB) CPU VCPUs State Time(s)
> > Domain-0 0 495 - 4 r----- 96.5
> > 11_create_0 73 16 3 1 -b---- 0.3
> > x335b:/tmp/ltp-full-20050804 # xm list
> > Name ID Mem(MiB) CPU VCPUs State Time(s)
> > Domain-0 0 495 - 4 r----- 96.5
> > 11_create_0 73 16 3 1 -b---- 0.3
> > x335b:/tmp/ltp-full-20050804 #
> > x335b:/tmp/ltp-full-20050804 # date
> > Thu Oct 13 13:47:59 CDT 2005
>
> I didn't expect this. Need to think some.
>
> > > Can you narrow down which of the xm-tests actually
> > provoke's the bug?
>
I believe it is 11_create_concurrent_pos.py that's provoking this bug.
> Can you repro using just this test?
I will try.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
--
Regards,
David F Barrera
Linux Technology Center
Systems and Technology Group, IBM
"The wisest men follow their own direction. "
Euripides
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |