xm dmesg output

xm dmesg output

[David F Barrera]

I am seeing a series of messages in 'xm dmesg' on a couple of machines.
They look like informational messages, but I would like to ensure that
they are not problem diagnostics. Any ideas?

(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff80100000->ffffffff8063d086
(XEN)  Init. ramdisk: ffffffff8063e000->ffffffff8063e000
(XEN)  Phys-Mach map: ffffffff8063e000->ffffffff806bb000
(XEN)  Start info:    ffffffff806bb000->ffffffff806bc000
(XEN)  Page tables:   ffffffff806bc000->ffffffff806c3000
(XEN)  Boot stack:    ffffffff806c3000->ffffffff806c4000
(XEN)  TOTAL:         ffffffff80000000->ffffffff80800000
(XEN)  ENTRY ADDRESS: ffffffff80100000
(XEN) Scrubbing Free RAM: .Scheduler: Simple EDF Scheduler (sedf)
(XEN) NOW=0x0000000001BFA244
(XEN) CPU[00] now=29343064
(XEN) RUNQ rq ffff830000ffdf00   n: ffff830000ffdf00, p:
ffff830000ffdf00
(XEN)
(XEN) WAITQ rq ffff830000ffdf10   n: ffff830000ffdf10, p:
ffff830000ffdf10
(XEN)
(XEN) EXTRAQ (penalty) rq ffff830000ffdf20   n: ffff830000ffdf20, p:
ffff830000ffdf20
(XEN)
(XEN) EXTRAQ (utilization) rq ffff830000ffdf30   n: ffff830000ffdf30, p:
ffff830000ffdf30
(XEN)
(XEN) not on Q
(XEN)   0: 0.0 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0
xtr(yes)=0 ew=0
(XEN) CPU[01] now=29365435
(XEN) RUNQ rq ffff830000ffcf00   n: ffff830000ffcf00, p:
ffff830000ffcf00
(XEN)
(XEN) WAITQ rq ffff830000ffcf10   n: ffff830000ffcf10, p:
ffff830000ffcf10
(XEN)
(XEN) EXTRAQ (penalty) rq ffff830000ffcf20   n: ffff830000ffcf20, p:
ffff830000ffcf20
(XEN)
(XEN) EXTRAQ (utilization) rq ffff830000ffcf30   n: ffff830000ffcf30, p:
ffff830000ffcf30
(XEN)
(XEN) not on Q
(XEN)   0: 0.1 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0
xtr(yes)=0 ew=0
(XEN) CPU[02] now=29384351
(XEN) RUNQ rq ffff830000ff7f00   n: ffff830000ff7f00, p:
ffff830000ff7f00
(XEN)
(XEN) WAITQ rq ffff830000ff7f10   n: ffff830000ff7f10, p:
ffff830000ff7f10
(XEN)
(XEN) EXTRAQ (penalty) rq ffff830000ff7f20   n: ffff830000ff7f20, p:
ffff830000ff7f20
(XEN)
(XEN) EXTRAQ (utilization) rq ffff830000ff7f30   n: ffff830000ff7f30, p:
ffff830000ff7f30
(XEN)
(XEN) not on Q
(XEN)   0: 0.2 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0
xtr(yes)=0 ew=0
(XEN) CPU[03] now=29403124
(XEN) RUNQ rq ffff830000ff6f00   n: ffff830000ff6f00, p:
ffff830000ff6f00
(XEN)
(XEN) WAITQ rq ffff830000ff6f10   n: ffff830000ff6f10, p:
ffff830000ff6f10
(XEN)
(XEN) EXTRAQ (penalty) rq ffff830000ff6f20   n: ffff830000ff6f20, p:
ffff830000ff6f20
(XEN)
(XEN) EXTRAQ (utilization) rq ffff830000ff6f30   n: ffff830000ff6f30, p:
ffff830000ff6f30
(XEN)
(XEN) not on Q
(XEN)   0: 0.3 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0
xtr(yes)=0 ew=0
(XEN) .Scheduler: Simple EDF Scheduler (sedf)
(XEN) NOW=0x0000000002D576BB
(XEN) CPU[00] now=47557977
(XEN) RUNQ rq ffff830000ffdf00   n: ffff830000ffdf00, p:
ffff830000ffdf00
(XEN)
(XEN) WAITQ rq ffff830000ffdf10   n: ffff830000ffdf10, p:
ffff830000ffdf10
(XEN)
(XEN) EXTRAQ (penalty) rq ffff830000ffdf20   n: ffff830000ffdf20, p:
ffff830000ffdf20
(XEN)
(XEN) EXTRAQ (utilization) rq ffff830000ffdf30   n: ffff830000ffdf30, p:
ffff830000ffdf30
(XEN)
(XEN) not on Q
(XEN)   0: 0.0 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0
xtr(yes)=0 ew=0
(XEN) CPU[01] now=47586667
(XEN) RUNQ rq ffff830000ffcf00   n: ffff830000ffcf00, p:
ffff830000ffcf00
(XEN)
(XEN) WAITQ rq ffff830000ffcf10   n: ffff830000ffcf10, p:
ffff830000ffcf10
(XEN)
(XEN) EXTRAQ (penalty) rq ffff830000ffcf20   n: ffff830000ffcf20, p:
ffff830000ffcf20
(XEN)
(XEN) EXTRAQ (utilization) rq ffff830000ffcf30   n: ffff830000ffcf30, p:
ffff830000ffcf30
(XEN)
(XEN) not on Q
(XEN)   0: 0.1 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0
xtr(yes)=0 ew=0
(XEN) CPU[02] now=47609090
(XEN) RUNQ rq ffff830000ff7f00   n: ffff830000ff7f00, p:
ffff830000ff7f00
(XEN)
(XEN) WAITQ rq ffff830000ff7f10   n: ffff830000ff7f10, p:
ffff830000ff7f10
(XEN)
(XEN) EXTRAQ (penalty) rq ffff830000ff7f20   n: ffff830000ff7f20, p:
ffff830000ff7f20
(XEN)
(XEN) EXTRAQ (utilization) rq ffff830000ff7f30   n: ffff830000ff7f30, p:
ffff830000ff7f30
(XEN)
(XEN) not on Q
(XEN)   0: 0.2 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0
xtr(yes)=0 ew=0
(XEN) CPU[03] now=47631303
(XEN) RUNQ rq ffff830000ff6f00   n: ffff830000ff6f00, p:
ffff830000ff6f00
(XEN)
(XEN) WAITQ rq ffff830000ff6f10   n: ffff830000ff6f10, p:
ffff830000ff6f10
(XEN)
(XEN) EXTRAQ (penalty) rq ffff830000ff6f20   n: ffff830000ff6f20, p:
ffff830000ff6f20
(XEN)
(XEN) EXTRAQ (utilization) rq ffff830000ff6f30   n: ffff830000ff6f30, p:
ffff830000ff6f30
(XEN)
(XEN) not on Q
(XEN)   0: 0.3 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0
xtr(yes)=0 ew=0
(XEN) Scheduler: Simple EDF Scheduler (sedf)
(XEN) NOW=0x0000000004327FC6
(XEN) CPU[00] now=70424763
(XEN) RUNQ rq ffff830000ffdf00   n: ffff830000ffdf00, p:
ffff830000ffdf00
(XEN)
(XEN) WAITQ rq ffff830000ffdf10   n: ffff830000ffdf10, p:
ffff830000ffdf10
(XEN)
(XEN) EXTRAQ (penalty) rq ffff830000ffdf20   n: ffff830000ffdf20, p:
ffff830000ffdf20
(XEN)
(XEN) EXTRAQ (utilization) rq ffff830000ffdf30   n: ffff830000ffdf30, p:
ffff830000ffdf30
(XEN)
(XEN) not on Q
(XEN)   0: 0.0 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0
xtr(yes)=0 ew=0
(XEN) CPU[01] now=70447104
(XEN) RUNQ rq ffff830000ffcf00   n: ffff830000ffcf00, p:
ffff830000ffcf00
(XEN)
(XEN) WAITQ rq ffff830000ffcf10   n: ffff830000ffcf10, p:
ffff830000ffcf10
(XEN)
(XEN) EXTRAQ (penalty) rq ffff830000ffcf20   n: ffff830000ffcf20, p:
ffff830000ffcf20
(XEN)
(XEN) EXTRAQ (utilization) rq ffff830000ffcf30   n: ffff830000ffcf30, p:
ffff830000ffcf30
(XEN)
(XEN) not on Q
(XEN)   0: 0.1 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0
xtr(yes)=0 ew=0
(XEN) CPU[02] now=70468852
(XEN) RUNQ rq ffff830000ff7f00   n: ffff830000ff7f00, p:
ffff830000ff7f00
(XEN)
(XEN) WAITQ rq ffff830000ff7f10   n: ffff830000ff7f10, p:
ffff830000ff7f10
(XEN)
(XEN) EXTRAQ (penalty) rq ffff830000ff7f20   n: ffff830000ff7f20, p:
ffff830000ff7f20
(XEN)
(XEN) EXTRAQ (utilization) rq ffff830000ff7f30   n: ffff830000ff7f30, p:
ffff830000ff7f30
(XEN)
(XEN) not on Q
(XEN)   0: 0.2 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0
xtr(yes)=0 ew=0
(XEN) CPU[03] now=70487524
(XEN) RUNQ rq ffff830000ff6f00   n: ffff830000ff6f00, p:
ffff830000ff6f00
(XEN)
(XEN) WAITQ rq ffff830000ff6f10   n: ffff830000ff6f10, p:
ffff830000ff6f10
(XEN)
(XEN) EXTRAQ (penalty) rq ffff830000ff6f20   n: ffff830000ff6f20, p:
ffff830000ff6f20
(XEN)
(XEN) EXTRAQ (utilization) rq ffff830000ff6f30   n: ffff830000ff6f30, p:
ffff830000ff6f30
(XEN)
(XEN) not on Q
(XEN)   0: 0.3 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0
xtr(yes)=0 ew=0
(XEN) .........done.
(XEN) Xen trace buffers: disabled
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xe



David F Barrera

Re: xm dmesg output

[Keir Fraser]

On 28 Nov 2005, at 21:11, David F Barrera wrote:

> I am seeing a series of messages in 'xm dmesg' on a couple of machines.
> They look like informational messages, but I would like to ensure that
> they are not problem diagnostics. Any ideas?

Someone redirected serial input to Xen (CTRL-a three times) and then 
pressed 'r' over the serial line to dump scheduler information. That is 
the only way that info can get printed.

  -- Keir

Re: xm dmesg output

[Adam Heath]

On Tue, 29 Nov 2005, Keir Fraser wrote:

>
> On 28 Nov 2005, at 21:11, David F Barrera wrote:
>
> > I am seeing a series of messages in 'xm dmesg' on a couple of machines.
> > They look like informational messages, but I would like to ensure that
> > they are not problem diagnostics. Any ideas?
>
> Someone redirected serial input to Xen (CTRL-a three times) and then
> pressed 'r' over the serial line to dump scheduler information. That is
> the only way that info can get printed.

Speaking of "xm dmesg", because xm is in /usr/sbin, it implies that a normal
user wouldn't normally need to run it.

However, xm provides several informational commands, dmesg being just one of
them.  And, since the normal dmesg is in /bin, it might make sense to have
them available in /usr/bin as well.

However, this could just be done with a shell script wrapper.  Would such a
patch be accepted?

RE: xm dmesg output

[Ian Pratt]

 
> Speaking of "xm dmesg", because xm is in /usr/sbin, it 
> implies that a normal user wouldn't normally need to run it.
> 
> However, xm provides several informational commands, dmesg 
> being just one of them.  And, since the normal dmesg is in 
> /bin, it might make sense to have them available in /usr/bin as well.
> 
> However, this could just be done with a shell script wrapper. 
>  Would such a patch be accepted?

Having a wrapper to make xm available in /usr/sbin/ and /usr/bin seems
pretty gross. It should be in one or the other, but I'm willing to
accept it may currently be in the wrong one. Let's see if anyone has a
strong opinion...

Ian

Re: xm dmesg output

[David F Barrera]

Keir Fraser wrote:

>
> On 28 Nov 2005, at 21:11, David F Barrera wrote:
>
>> I am seeing a series of messages in 'xm dmesg' on a couple of machines.
>> They look like informational messages, but I would like to ensure that
>> they are not problem diagnostics. Any ideas?
>
>
> Someone redirected serial input to Xen (CTRL-a three times) and then 
> pressed 'r' over the serial line to dump scheduler information. That 
> is the only way that info can get printed.

The interesting thing is that no one is doing anything to the serial 
input! This is happening 'spontaneously' in my setup.  Sounds like a bug?

>
>  -- Keir
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> 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

Re: xm dmesg output

[Horms]

Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:
> 
>> Speaking of "xm dmesg", because xm is in /usr/sbin, it 
>> implies that a normal user wouldn't normally need to run it.
>> 
>> However, xm provides several informational commands, dmesg 
>> being just one of them.  And, since the normal dmesg is in 
>> /bin, it might make sense to have them available in /usr/bin as well.
>> 
>> However, this could just be done with a shell script wrapper. 
>>  Would such a patch be accepted?
> 
> Having a wrapper to make xm available in /usr/sbin/ and /usr/bin seems
> pretty gross. It should be in one or the other, but I'm willing to
> accept it may currently be in the wrong one. Let's see if anyone has a
> strong opinion...

As I understand the way that sbin vs bin is supposed to work,
sbin is for commands that can only ever be executed by root.
And make no sense to be invoked by a normal user. The idea
being that administrative commands can be moved out of bin
to avoid cluttering users' paths. However, if commands that
users might want to access are in sbin, then users tend
to put sbin in their path so they can see them, thus negating
much of the benifit of the bin/sbin split.

So in short, if xm has a mode of invocation that makes sense for
non-root users, it should be in bin so both root and non-root users
see it without having to fiddle their paths.

-- 
Horms

Re: xm dmesg output

[Keir Fraser]

On 29 Nov 2005, at 22:15, David F Barrera wrote:

>> Someone redirected serial input to Xen (CTRL-a three times) and then 
>> pressed 'r' over the serial line to dump scheduler information. That 
>> is the only way that info can get printed.
>
> The interesting thing is that no one is doing anything to the serial 
> input! This is happening 'spontaneously' in my setup.  Sounds like a 
> bug?

Yes, if that really is the case. It looks impossible though. That 
diagnostic output is only triggered from handle_keypress(), which is 
only called from serial_rx(), which is only called from the low-level 
serial driver.

  -- Keir

Re: xm dmesg output

[Anthony Liguori]

Adam Heath wrote:

>Speaking of "xm dmesg", because xm is in /usr/sbin, it implies that a normal
>user wouldn't normally need to run it.
>  
>
xm dmesg requires root privileges (in order to make the readconsolering 
hypercall) which means that it can only be run by root.  There's no 
point in cluttering a user's path with things that he cannot run :-)  
The only exception would be users with sudo privileges.  I think it's 
common enough to put /usr/sbin and /sbin in sudo users PATHs though so 
they don't need it in /usr/bin.

Regards,

Anthony Liguori

>However, xm provides several informational commands, dmesg being just one of
>them.  And, since the normal dmesg is in /bin, it might make sense to have
>them available in /usr/bin as well.
>
>However, this could just be done with a shell script wrapper.  Would such a
>patch be accepted?
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>
>  
>

Re: xm dmesg output

[David F Barrera]

On Wed, 2005-11-30 at 11:39 +0000, Keir Fraser wrote:
> On 29 Nov 2005, at 22:15, David F Barrera wrote:
> 
> >> Someone redirected serial input to Xen (CTRL-a three times) and then 
> >> pressed 'r' over the serial line to dump scheduler information. That 
> >> is the only way that info can get printed.
> >
> > The interesting thing is that no one is doing anything to the serial 
> > input! This is happening 'spontaneously' in my setup.  Sounds like a 
> > bug?
> 
> Yes, if that really is the case. It looks impossible though. That 
> diagnostic output is only triggered from handle_keypress(), which is 
> only called from serial_rx(), which is only called from the low-level 
> serial driver.
> 
Well, it is the case. There hasn't been anything done on the serial
console to cause it; it is happening 'spontaneously'.

[root@leaf10 ~]# xm dmesg
 __  __            _____  ___         _                _
 \ \/ /___ _ __   |___ / / _ \     __| | _____   _____| |
  \  // _ \ '_ \    |_ \| | | |__ / _` |/ _ \ \ / / _ \ |
  /  \  __/ | | |  ___) | |_| |__| (_| |  __/\ V /  __/ |
 /_/\_\___|_| |_| |____(_)___/    \__,_|\___| \_/ \___|_|

 http://www.cl.cam.ac.uk/netos/xen
 University of Cambridge Computer Laboratory

 Xen version 3.0-devel (root@) (gcc version 3.4.4 20050721 (Red Hat
3.4.4-2)) Thu Dec  1 09:52:50 CST 2005
 Latest ChangeSet: Thu Dec  1 08:22:22 2005 +0100 8151:f5b119533cc8

(XEN) Physical RAM map:
(XEN)  0000000000000000 - 000000000009d400 (usable)
(XEN)  000000000009d400 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000d7fbe640 (usable)
(XEN)  00000000d7fbe640 - 00000000d7fd0000 (ACPI data)
(XEN)  00000000d7fd0000 - 00000000d8000000 (reserved)
(XEN)  00000000fec00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000228000000 (usable)
(XEN) System RAM: 8191MB (8387948kB)
(XEN) Xen heap: 10MB (10360kB)
(XEN) PAE enabled, limit: 16 GB
(XEN) found SMP MP-table at 0009d540
(XEN) DMI 2.3 present.
(XEN) Using APIC driver default
(XEN) ACPI: RSDP (v000 IBM                                   ) @
0x000fdfc0
(XEN) ACPI: RSDT (v001 IBM    SERBLADE 0x00001000 IBM  0x45444f43) @
0xd7fcff80
(XEN) ACPI: FADT (v002 IBM    SERBLADE 0x00001000 IBM  0x45444f43) @
0xd7fcfec0
(XEN) ACPI: MADT (v001 IBM    SERBLADE 0x00001000 IBM  0x45444f43) @
0xd7fcfe00
(XEN) ACPI: MCFG (v001 IBM    SERBLADE 0x00001000 IBM  0x45444f43) @
0xd7fcfdc0
(XEN) ACPI: DSDT (v001 IBM    SERBLADE 0x00001000 INTL 0x02002025) @
0x00000000
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 15:4 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x06] enabled)
(XEN) Processor #6 15:4 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
(XEN) Processor #1 15:4 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x07] enabled)
(XEN) Processor #7 15:4 APIC version 20
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1])
(XEN) ACPI: IOAPIC (id[0x0e] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 14, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x0d] address[0xfec10000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 13, version 32, address 0xfec10000, GSI 24-47
(XEN) ACPI: IOAPIC (id[0x0c] address[0xfec81000] gsi_base[48])
(XEN) IOAPIC[2]: apic_id 12, version 32, address 0xfec81000, GSI 48-71
(XEN) ACPI: IOAPIC (id[0x0b] address[0xfec81400] gsi_base[72])
(XEN) IOAPIC[3]: apic_id 11, version 32, address 0xfec81400, GSI 72-95
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ11 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 4 I/O APICs
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) Initializing CPU#0
(XEN) Detected 3200.228 MHz processor.
(XEN) Using scheduler: Simple EDF Scheduler (sedf)
(XEN) CPU: Trace cache: 12K uops, L1 D cache: 16K
(XEN) CPU: L2 cache: 1024K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU0: Intel(R) Xeon(TM) CPU 3.20GHz stepping 01
(XEN) Booting processor 1/1 eip 90000
(XEN) Initializing CPU#1
(XEN) CPU: Trace cache: 12K uops, L1 D cache: 16K
(XEN) CPU: L2 cache: 1024K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU1: Intel(R) Xeon(TM) CPU 3.20GHz stepping 01
(XEN) Booting processor 2/6 eip 90000
(XEN) Initializing CPU#2
(XEN) CPU: Trace cache: 12K uops, L1 D cache: 16K
(XEN) CPU: L2 cache: 1024K
(XEN) CPU: Physical Processor ID: 3
(XEN) CPU2: Intel(R) Xeon(TM) CPU 3.20GHz stepping 01
(XEN) Booting processor 3/7 eip 90000
(XEN) Initializing CPU#3
(XEN) CPU: Trace cache: 12K uops, L1 D cache: 16K
(XEN) CPU: L2 cache: 1024K
(XEN) CPU: Physical Processor ID: 3
(XEN) CPU3: Intel(R) Xeon(TM) CPU 3.20GHz stepping 01
(XEN) Total of 4 processors activated.
(XEN) ENABLING IO-APIC IRQs
(XEN) ..TIMER: vector=0x31 pin1=2 pin2=-1
(XEN) checking TSC synchronization across 4 CPUs: passed.
(XEN) Platform timer is 1.193MHz PIT
(XEN) Brought up 4 CPUs
(XEN) mtrr: v2.0 (20020519)
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Xen-ELF header found:
'GUEST_OS=linux,GUEST_VER=2.6,XEN_VER=3.0,VIRT_BASE=0xC0000000,PAE=yes,LOADER=generic'
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000005000000->0000000006000000 (251904 pages
to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: c0100000->c05f5184
(XEN)  Init. ramdisk: c05f6000->c083da00
(XEN)  Phys-Mach map: c083e000->c0938000
(XEN)  Start info:    c0938000->c0939000
(XEN)  Page tables:   c0939000->c0944000
(XEN)  Boot stack:    c0944000->c0945000
(XEN)  TOTAL:         c0000000->c0c00000
(XEN)  ENTRY ADDRESS: c0100000
(XEN) Initrd len 0x247a00, start at 0xc05f6000
(XEN) Scrubbing Free RAM: .Scheduler: Simple EDF Scheduler (sedf)
(XEN) NOW=0x00000000022093BB
(XEN) CPU[00] now=35695933
(XEN) RUNQ rq ff1e5c00   n: ff1e5c00, p: ff1e5c00
(XEN)
(XEN) WAITQ rq ff1e5c08   n: ff1e5c08, p: ff1e5c08
(XEN)
(XEN) EXTRAQ (penalty) rq ff1e5c10   n: ff1e5c10, p: ff1e5c10
(XEN)
(XEN) EXTRAQ (utilization) rq ff1e5c18   n: ff1e5c18, p: ff1e5c18
(XEN)
(XEN) not on Q
(XEN)   0: 0.0 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0 xtr
(yes)=0 ew=0
(XEN) CPU[01] now=35741039
(XEN) RUNQ rq ff1e4980   n: ff1e4980, p: ff1e4980
(XEN)
(XEN) WAITQ rq ff1e4988   n: ff1e4988, p: ff1e4988
(XEN)
(XEN) EXTRAQ (penalty) rq ff1e4990   n: ff1e4990, p: ff1e4990
(XEN)
(XEN) EXTRAQ (utilization) rq ff1e4998   n: ff1e4998, p: ff1e4998
(XEN)
(XEN) not on Q
(XEN)   0: 0.1 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0 xtr
(yes)=0 ew=0
(XEN) CPU[02] now=35783361
(XEN) RUNQ rq ffbfa980   n: ffbfa980, p: ffbfa980
(XEN)
(XEN) WAITQ rq ffbfa988   n: ffbfa988, p: ffbfa988
(XEN)
(XEN) EXTRAQ (penalty) rq ffbfa990   n: ffbfa990, p: ffbfa990
(XEN)
(XEN) EXTRAQ (utilization) rq ffbfa998   n: ffbfa998, p: ffbfa998
(XEN)
(XEN) not on Q
(XEN)   0: 0.2 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0 xtr
(yes)=0 ew=0
(XEN) CPU[03] now=35825616
(XEN) RUNQ rq ff1ee980   n: ff1ee980, p: ff1ee980
(XEN)
(XEN) WAITQ rq ff1ee988   n: ff1ee988, p: ff1ee988
(XEN)
(XEN) EXTRAQ (penalty) rq ff1ee990   n: ff1ee990, p: ff1ee990
(XEN)
(XEN) EXTRAQ (utilization) rq ff1ee998   n: ff1ee998, p: ff1ee998
(XEN)
(XEN) not on Q
(XEN)   0: 0.3 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0 xtr
(yes)=0 ew=0
(XEN) Scheduler: Simple EDF Scheduler (sedf)
(XEN) NOW=0x000000000335A280
(XEN) CPU[00] now=53860610
(XEN) RUNQ rq ff1e5c00   n: ff1e5c00, p: ff1e5c00
(XEN)
(XEN) WAITQ rq ff1e5c08   n: ff1e5c08, p: ff1e5c08
(XEN)
(XEN) EXTRAQ (penalty) rq ff1e5c10   n: ff1e5c10, p: ff1e5c10
(XEN)
(XEN) EXTRAQ (utilization) rq ff1e5c18   n: ff1e5c18, p: ff1e5c18
(XEN)
(XEN) not on Q
(XEN)   0: 0.0 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0 xtr
(yes)=0 ew=0
(XEN) CPU[01] now=53908530
(XEN) RUNQ rq ff1e4980   n: ff1e4980, p: ff1e4980
(XEN)
(XEN) WAITQ rq ff1e4988   n: ff1e4988, p: ff1e4988
(XEN)
(XEN) EXTRAQ (penalty) rq ff1e4990   n: ff1e4990, p: ff1e4990
(XEN)
(XEN) EXTRAQ (utilization) rq ff1e4998   n: ff1e4998, p: ff1e4998
(XEN)
(XEN) not on Q
(XEN)   0: 0.1 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0 xtr
(yes)=0 ew=0
(XEN) CPU[02] now=53951275
(XEN) RUNQ rq ffbfa980   n: ffbfa980, p: ffbfa980
(XEN)
(XEN) WAITQ rq ffbfa988   n: ffbfa988, p: ffbfa988
(XEN)
(XEN) EXTRAQ (penalty) rq ffbfa990   n: ffbfa990, p: ffbfa990
(XEN)
(XEN) EXTRAQ (utilization) rq ffbfa998   n: ffbfa998, p: ffbfa998
(XEN)
(XEN) not on Q
(XEN)   0: 0.2 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0 xtr
(yes)=0 ew=0
(XEN) CPU[03] now=53993685
(XEN) RUNQ rq ff1ee980   n: ff1ee980, p: ff1ee980
(XEN)
(XEN) WAITQ rq ff1ee988   n: ff1ee988, p: ff1ee988
(XEN)
(XEN) EXTRAQ (penalty) rq ff1ee990   n: ff1ee990, p: ff1ee990
(XEN)
(XEN) EXTRAQ (utilization) rq ff1ee998   n: ff1ee998, p: ff1ee998
(XEN)
(XEN) not on Q
(XEN)   0: 0.3 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0 xtr
(yes)=0 ew=0
(XEN) .Scheduler: Simple EDF Scheduler (sedf)
(XEN) NOW=0x000000000492C724
(XEN) CPU[00] now=76735407
(XEN) RUNQ rq ff1e5c00   n: ff1e5c00, p: ff1e5c00
(XEN)
(XEN) WAITQ rq ff1e5c08   n: ff1e5c08, p: ff1e5c08
(XEN)
(XEN) EXTRAQ (penalty) rq ff1e5c10   n: ff1e5c10, p: ff1e5c10
(XEN)
(XEN) EXTRAQ (utilization) rq ff1e5c18   n: ff1e5c18, p: ff1e5c18
(XEN)
(XEN) not on Q
(XEN)   0: 0.0 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0 xtr
(yes)=0 ew=0
(XEN) CPU[01] now=76778635
(XEN) RUNQ rq ff1e4980   n: ff1e4980, p: ff1e4980
(XEN)
(XEN) WAITQ rq ff1e4988   n: ff1e4988, p: ff1e4988
(XEN)
(XEN) EXTRAQ (penalty) rq ff1e4990   n: ff1e4990, p: ff1e4990
(XEN)
(XEN) EXTRAQ (utilization) rq ff1e4998   n: ff1e4998, p: ff1e4998
(XEN)
(XEN) not on Q
(XEN)   0: 0.1 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0 xtr
(yes)=0 ew=0
(XEN) CPU[02] now=76820737
(XEN) RUNQ rq ffbfa980   n: ffbfa980, p: ffbfa980
(XEN)
(XEN) WAITQ rq ffbfa988   n: ffbfa988, p: ffbfa988
(XEN)
(XEN) EXTRAQ (penalty) rq ffbfa990   n: ffbfa990, p: ffbfa990
(XEN)
(XEN) EXTRAQ (utilization) rq ffbfa998   n: ffbfa998, p: ffbfa998
(XEN)
(XEN) not on Q
(XEN)   0: 0.2 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0 xtr
(yes)=0 ew=0
(XEN) CPU[03] now=76862654
(XEN) RUNQ rq ff1ee980   n: ff1ee980, p: ff1ee980
(XEN)
(XEN) WAITQ rq ff1ee988   n: ff1ee988, p: ff1ee988
(XEN)
(XEN) EXTRAQ (penalty) rq ff1ee990   n: ff1ee990, p: ff1ee990
(XEN)
(XEN) EXTRAQ (utilization) rq ff1ee998   n: ff1ee998, p: ff1ee998
(XEN)
(XEN) not on Q
(XEN)   0: 0.3 has=F p=20000000 sl=15000000 ddl=0 w=0 c=0 sc=0 xtr
(yes)=0 ew=0
(XEN) .......................................................................................done.
(XEN) Xen trace buffers: disabled
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen).
(XEN) microcode: CPU0 not 'upgrading' to earlier revision 0x9
(current=0x12)
(XEN) microcode: CPU1 not 'upgrading' to earlier revision 0x9
(current=0x12)
(XEN) microcode: CPU2 not 'upgrading' to earlier revision 0x9
(current=0x12)
(XEN) microcode: CPU3 not 'upgrading' to earlier revision 0x9
(current=0x12)
(XEN) microcode: No suitable data for CPU2
(XEN) microcode: No suitable data for CPU1
(XEN) microcode: No suitable data for CPU3
(XEN) microcode: No suitable data for CPU0

>   -- Keir
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> 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

Re: xm dmesg output

[Adam Heath]

On Thu, 1 Dec 2005, David F Barrera wrote:

> On Wed, 2005-11-30 at 11:39 +0000, Keir Fraser wrote:
> > On 29 Nov 2005, at 22:15, David F Barrera wrote:
> >
> > >> Someone redirected serial input to Xen (CTRL-a three times) and then
> > >> pressed 'r' over the serial line to dump scheduler information. That
> > >> is the only way that info can get printed.
> > >
> > > The interesting thing is that no one is doing anything to the serial
> > > input! This is happening 'spontaneously' in my setup.  Sounds like a
> > > bug?
> >
> > Yes, if that really is the case. It looks impossible though. That
> > diagnostic output is only triggered from handle_keypress(), which is
> > only called from serial_rx(), which is only called from the low-level
> > serial driver.
> >
> Well, it is the case. There hasn't been anything done on the serial
> console to cause it; it is happening 'spontaneously'.

Noise on the serial line?

Re: xm dmesg output

[David F Barrera]

On Thu, 2005-12-01 at 12:37 -0600, Adam Heath wrote:

> > >
> > Well, it is the case. There hasn't been anything done on the serial
> > console to cause it; it is happening 'spontaneously'.
> 
> Noise on the serial line?
It's possible. It has happened several times on at least two machines.
> 

-- 
Regards,

David F Barrera
Linux Technology Center
Systems and Technology Group, IBM

"The wisest men follow their own direction. "
                                                        Euripides