* xm dmesg output @ 2005-11-28 21:11 David F Barrera 2005-11-29 10:26 ` Keir Fraser 0 siblings, 1 reply; 11+ messages in thread From: David F Barrera @ 2005-11-28 21:11 UTC (permalink / raw) To: xen-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: xm dmesg output 2005-11-28 21:11 xm dmesg output David F Barrera @ 2005-11-29 10:26 ` Keir Fraser 2005-11-29 17:15 ` Adam Heath 2005-11-29 22:15 ` David F Barrera 0 siblings, 2 replies; 11+ messages in thread From: Keir Fraser @ 2005-11-29 10:26 UTC (permalink / raw) To: David F Barrera; +Cc: xen-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: xm dmesg output 2005-11-29 10:26 ` Keir Fraser @ 2005-11-29 17:15 ` Adam Heath 2005-11-30 16:15 ` Anthony Liguori 2005-11-29 22:15 ` David F Barrera 1 sibling, 1 reply; 11+ messages in thread From: Adam Heath @ 2005-11-29 17:15 UTC (permalink / raw) Cc: xen-devel 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: xm dmesg output 2005-11-29 17:15 ` Adam Heath @ 2005-11-30 16:15 ` Anthony Liguori 0 siblings, 0 replies; 11+ messages in thread From: Anthony Liguori @ 2005-11-30 16:15 UTC (permalink / raw) To: Adam Heath; +Cc: xen-devel 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 > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: xm dmesg output 2005-11-29 10:26 ` Keir Fraser 2005-11-29 17:15 ` Adam Heath @ 2005-11-29 22:15 ` David F Barrera 2005-11-30 11:39 ` Keir Fraser 1 sibling, 1 reply; 11+ messages in thread From: David F Barrera @ 2005-11-29 22:15 UTC (permalink / raw) To: Keir Fraser; +Cc: xen-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: xm dmesg output 2005-11-29 22:15 ` David F Barrera @ 2005-11-30 11:39 ` Keir Fraser 2005-12-01 17:49 ` David F Barrera 0 siblings, 1 reply; 11+ messages in thread From: Keir Fraser @ 2005-11-30 11:39 UTC (permalink / raw) To: David F Barrera; +Cc: xen-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: xm dmesg output 2005-11-30 11:39 ` Keir Fraser @ 2005-12-01 17:49 ` David F Barrera 2005-12-01 18:37 ` Adam Heath 0 siblings, 1 reply; 11+ messages in thread From: David F Barrera @ 2005-12-01 17:49 UTC (permalink / raw) To: Keir Fraser; +Cc: xen-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: xm dmesg output 2005-12-01 17:49 ` David F Barrera @ 2005-12-01 18:37 ` Adam Heath 2005-12-01 19:04 ` David F Barrera 0 siblings, 1 reply; 11+ messages in thread From: Adam Heath @ 2005-12-01 18:37 UTC (permalink / raw) Cc: xen-devel 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: xm dmesg output 2005-12-01 18:37 ` Adam Heath @ 2005-12-01 19:04 ` David F Barrera 0 siblings, 0 replies; 11+ messages in thread From: David F Barrera @ 2005-12-01 19:04 UTC (permalink / raw) To: Adam Heath; +Cc: xen-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: xm dmesg output
@ 2005-11-29 17:58 Ian Pratt
2005-11-30 2:46 ` Horms
0 siblings, 1 reply; 11+ messages in thread
From: Ian Pratt @ 2005-11-29 17:58 UTC (permalink / raw)
To: Adam Heath; +Cc: xen-devel
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: xm dmesg output 2005-11-29 17:58 Ian Pratt @ 2005-11-30 2:46 ` Horms 0 siblings, 0 replies; 11+ messages in thread From: Horms @ 2005-11-30 2:46 UTC (permalink / raw) To: xen-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2005-12-01 19:04 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-11-28 21:11 xm dmesg output David F Barrera 2005-11-29 10:26 ` Keir Fraser 2005-11-29 17:15 ` Adam Heath 2005-11-30 16:15 ` Anthony Liguori 2005-11-29 22:15 ` David F Barrera 2005-11-30 11:39 ` Keir Fraser 2005-12-01 17:49 ` David F Barrera 2005-12-01 18:37 ` Adam Heath 2005-12-01 19:04 ` David F Barrera -- strict thread matches above, loose matches on Subject: below -- 2005-11-29 17:58 Ian Pratt 2005-11-30 2:46 ` Horms
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.