[Xen-ia64-devel] [PATCH][RFC] fix dom0 builder TAKE3
On Mon, Oct 16, 2006 at 02:41:40PM -0600, Alex Williamson wrote:
Yes, I think we'll need to switch to discontig/sparsemem for the dom0
kernel if the memmory map is going to reflect the bare metal hardware
memory layout. Unfortunately, just switching to discontig w/ virtual
memmap does not solve the problem I'm seeing. The dom0 kernel reports
the correct amount of memory early in bootup. Perhaps the balloon
driver is causing this(?) Thanks,
I looked into balloon driver and found that it doesn't take care of
sparsely populated memory.
How about those patches?
- dom0_initrd_start.patch
changed dom0's initrd image load area so that it follows start info.
It becomes non-sense to use dom0_size if dom0 memoy is assigned sparsely.
- fix_dom0_builder.patch
fix dom0 builder so that xen doesn't assign memory on I/O area.
- convmem_end.patch
split the meaning of struct domain::maxmem into struct
arch_domain::convmem_end so that maxmem means the number of pages which
domain has and convmem_end means the highest address of conventional
memory (i.e. RAM).
- max_mapnr_config_flatmem.patch
remove warning when !CONFIG_FLATMEM moving max_mapnr declaration.
- sparse_contiugous_bitmap.patch
allocate contiguous_bitmap sparsely like virtual memmap.
With dom0 memory assignment changed, memory might be sparse, so simple bitmap
may waste too much memory.
- fix_balloon_init.patch
make balloon driver not return pages which are in
[xen_start_info-nr_pages, max_pfn] on ia64.
On ia64 memory might be assigned sparsely. In that case
xen_start_info-nr_pages and max_pfn doesn't match while pages which are in
[xen_start_info-nr_pages, max_pfn] are used.
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1166586635 -32400
# Node ID 39d2b340885f1cf4367651e976c36ab7f29a051b
# Parent 8fc6b39c225608f03944cc642c685490cdf62a29
changed dom0's initrd image load area so that it follows start info.
It becomes non-sense to use dom0_size if dom0 memoy is assigned sparsely.
PATCHNAME: dom0_initrd_start
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 8fc6b39c2256 -r 39d2b340885f xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.cMon Dec 11 17:08:32 2006 +0900
+++ b/xen/arch/ia64/xen/domain.cWed Dec 20 12:50:35 2006 +0900
@@ -1051,10 +1051,12 @@ int construct_dom0(struct domain *d,
if(initrd_start initrd_len){
unsigned long offset;
- pinitrd_start= dom0_size - (PAGE_ALIGN(initrd_len) + 4*1024*1024);
- if (pinitrd_start = pstart_info)
- panic(%s:enough memory is not assigned to dom0, __func__);
-
+ /* the next page aligned boundary after the start info.
+ note:EFI_PAGE_SHIFT = 12 = PAGE_SHIFT */
+ pinitrd_start = pstart_info + PAGE_SIZE;
+ if (pinitrd_start + initrd_len = dom0_size)
+ panic(%s:enough memory is not assigned to dom0,
+ __func__);
for (offset = 0; offset initrd_len; offset += PAGE_SIZE) {
struct page_info *p;
p = assign_new_domain_page(d, pinitrd_start + offset);
@@ -1109,10 +,6 @@ int construct_dom0(struct domain *d,
/* Copy the OS image. */
loaddomainelfimage(d,image_start);
- /* Copy the initial ramdisk. */
- //if ( initrd_len != 0 )
- //memcpy((void *)vinitrd_start, initrd_start, initrd_len);
-
BUILD_BUG_ON(sizeof(start_info_t) + sizeof(dom0_vga_console_info_t) +
sizeof(struct ia64_boot_param) PAGE_SIZE);
@@ -1161,8 +1159,7 @@ int construct_dom0(struct domain *d,
bp-console_info.orig_y = bp-console_info.num_rows == 0 ?
0 : bp-console_info.num_rows - 1;
- bp-initrd_start = dom0_size -
-(PAGE_ALIGN(ia64_boot_param-initrd_size) + 4*1024*1024);
+ bp-initrd_start = pinitrd_start;
bp-initrd_size = ia64_boot_param-initrd_size;
ci = (dom0_vga_console_info_t *)((unsigned char *)si +
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1166691403 -32400
# Node ID 2f68d7084097db57cb43c82a7c74e08dde170392
# Parent 39d2b340885f1cf4367651e976c36ab7f29a051b
fix dom0 builder so that xen doesn't assign memory on I/O area.
PATCHNAME: fix_dom0_builder
Signed-off-by: Alex Williamson [EMAIL PROTECTED]
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 39d2b340885f -r 2f68d7084097 xen/arch/ia64/xen/dom_fw.c
--- a/xen/arch/ia64/xen/dom_fw.cWed Dec 20 12:50:35 2006 +0900
+++ b/xen/arch/ia64/xen/dom_fw.cThu Dec 21 17:56:43 2006 +0900
@@ -516,10 +516,10 @@ complete_dom0_memmap(struct domain *d,
{
efi_memory_desc_t *md;
u64 addr;
- int j;
void *efi_map_start, *efi_map_end, *p;
u64 efi_desc_size;
int i;
+ unsigned long leftmem = maxmem - (d-tot_pages PAGE_SHIFT);
/* Walk through all MDT entries.
Copy all interesting
Re: [Xen-ia64-devel][PATCH] vcpu_get_psr fix
On Thu, Dec 21, 2006 at 01:13:45PM +0800, Xu, Anthony wrote: This is only used by __kernel_syscall_via_epc function in xeno domain. previouly, break 0x19(XEN_HYPER_GET_PSR) is the second Instruction in the bundle. When I debugged the patch of remove the requirement (vpsr.ic==0) fromhyperprivop. break 0x19 is the third instruction in the bundle, this causes dom0 can't boot. This patch can resolve this. And this is correct emulation of mov from psr. Could you elaborate? I don't see why it causes booting trouble and masking vpsr resolves it. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch] make Xen assign meta-physical memory in spaces that match real hardware
Hi,
This is an initial patch to make Xen start assigning meta physical
memory in the physical ranges that match the hardware it is running
upon.
More work needs to be done in this area, but it is crucial we assign
memory correctly, in particular for dom0.
Cheers,
Jes
Currently Xen assigns memory to a dom by filling up the holes counting
from physical address zero.
This is inherently broken as the dom needs to map physical memory
chunks it receives onto the physical nodes of the system.
I'd like to suggest the following interim patch as a step in this
direction, by making Xen assign memory in the zones that map the
hardware.
On the longer term we need to keep track of what physical memory is
really assigned to what dom so the NUMA mapping matches reality.
We should also come up with a scheme so one can tell a dom to behave
like a virtual DIG box by forcing memory to start from address zero in
order to be able to run those underpriviledged operating systems that
cannot handle modern computers (a certain thing that nobody likes to
talk about comes to mind here).
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 665284c4a8e7 xen/arch/ia64/xen/dom_fw.c
--- a/xen/arch/ia64/xen/dom_fw.cTue Dec 19 12:41:21 2006 +0100
+++ b/xen/arch/ia64/xen/dom_fw.cThu Dec 21 15:31:57 2006 +0100
@@ -507,6 +507,12 @@ struct fw_tables {
#define FW_FIELD_MPA(field) \
FW_TABLES_BASE_PADDR + offsetof(struct fw_tables, field)
+/*
+ * This should be a boot line option, or even better, handled as a per
+ * dom property.
+ */
+int force_domU_lowmem;
+
/* Complete the dom0 memmap. */
static int
complete_dom0_memmap(struct domain *d,
@@ -515,7 +521,7 @@ complete_dom0_memmap(struct domain *d,
int num_mds)
{
efi_memory_desc_t *md;
- u64 addr;
+ u64 addr, mem_assigned, chunk_size;
int j;
void *efi_map_start, *efi_map_end, *p;
u64 efi_desc_size;
@@ -526,6 +532,8 @@ complete_dom0_memmap(struct domain *d,
efi_map_start = __va(ia64_boot_param-efi_memmap);
efi_map_end = efi_map_start + ia64_boot_param-efi_memmap_size;
efi_desc_size = ia64_boot_param-efi_memdesc_size;
+
+ mem_assigned = 0;
for (p = efi_map_start; p efi_map_end; p += efi_desc_size) {
const efi_memory_desc_t *md = p;
@@ -561,7 +569,6 @@ complete_dom0_memmap(struct domain *d,
num_mds++;
break;
- case EFI_CONVENTIONAL_MEMORY:
case EFI_LOADER_CODE:
case EFI_LOADER_DATA:
case EFI_BOOT_SERVICES_CODE:
@@ -588,6 +595,33 @@ complete_dom0_memmap(struct domain *d,
num_mds++;
break;
+ case EFI_CONVENTIONAL_MEMORY:
+ if (mem_assigned = maxmem)
+ break;
+
+ if (d != dom0 force_domU_lowmem)
+ break;
+
+ chunk_size = end - start;
+ /*
+* Eventually this needs to be made more
+* intelligent so it keeps track of what
+* memory was assigned to which dom so
+* NUMA information provided to the dom
+* is correct.
+*/
+ if ((mem_assigned + chunk_size) maxmem)
+ chunk_size = maxmem - mem_assigned;
+ dom_md-type = EFI_CONVENTIONAL_MEMORY;
+ dom_md-phys_addr = start;
+ dom_md-virt_addr = 0;
+ dom_md-num_pages = chunk_size EFI_PAGE_SHIFT;
+ dom_md-attribute = EFI_MEMORY_WB;
+ dom_md-pad = 0;
+ mem_assigned += chunk_size;
+ num_mds++;
+ break;
+
case EFI_UNUSABLE_MEMORY:
case EFI_PAL_CODE:
/* Discard. */
@@ -606,49 +642,50 @@ complete_dom0_memmap(struct domain *d,
/* find gaps and fill them with conventional memory */
i = num_mds;
- for (j = 0; j num_mds; j++) {
- unsigned long end;
- unsigned long next_start;
-
- md = tables-efi_memmap[j];
- end = md-phys_addr + (md-num_pages EFI_PAGE_SHIFT);
-
- if (j + 1 num_mds) {
- efi_memory_desc_t* next_md;
- next_md = tables-efi_memmap[j + 1];
- next_start = next_md-phys_addr;
-
- /* Have just been sorted. */
- BUG_ON(end next_start);
-
- /* No room for memory! */
- if (end ==
Re: [Xen-ia64-devel] [patch] make Xen assign meta-physical memory in spaces that match real hardware
Hi, Jes Isaku work this issue now. Could you see his patches? http://lists.xensource.com/archives/html/xen-ia64-devel/2006-12/msg00249.html Best Regards, Akio Takebe Hi, This is an initial patch to make Xen start assigning meta physical memory in the physical ranges that match the hardware it is running upon. More work needs to be done in this area, but it is crucial we assign memory correctly, in particular for dom0. Cheers, Jes ---text/plain--- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [Xen-devel] unnecessary VCPU migration happens again
Hi Emmanuel, Thanks for your quick response. I'm not familiar with scheduler, I'll study it. :-) I put comments below, maybe it's not right. :-) Emmanuel Ackaouy write on 2006年12月22日 0:23: Hi Anthony. Based on the number of ticks on CPU0 that occurred between the two stat dumps, over 16 minutes elapsed during that time. During that time, 364 regular migrations occurred. These are migrations that happen when an idle CPU finds a runnable VCPU queued elsewhere on the system. From the point of user of credit scheduler, it may be not regular migrations. Because there are 4 CPU, and there are only 3 VCPU, It would be unlikely that an idle CPU finds a runnable VCPU queued elsewhere on the system. Also during that time, 530 multi-core load balancing migrations happened. That's about one such migration every 1.86 seconds. I'm somewhat surprised that this costs 5% in performance of your benchmark. That said, the point of this code is to balance a partially idle system and not to shuffle things around too much so I'm happy to smooth the algorithm further to reduce the number of these migrations. I'm interested about this. I'll investigate this. I'll send another patch shortly. Thanks again. On Dec 20, 2006, at 4:26, Xu, Anthony wrote: Before running KB (XEN) migrate_queued = 169 (XEN) migrate_running= 213 (XEN) CPU[00] tick=117181, sort=12233, sibling=0x1, core=0x5 After running KB (XEN) migrate_queued = 533 (XEN) migrate_running= 743 (XEN) CPU[00] tick=215790, sort=42999, sibling=0x1, core=0x5 ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Crash-utility] crash version 4.0-3.15 is available
On Thu, Dec 21, 2006 at 08:54:23AM -0500, Dave Anderson wrote:
Isaku Yamahata wrote:
The current xm dump-core on ia64 loses some registers infomation
which is saved on xen register stack.
e.g. r33, ... aren't saved in domU xendump file.
Probably ia64 specific code would be necessarry for it.
This will be addressed as post-3.0.4 effort and the format will be
changed.
I'm not sure exactly what the ramifications are of an ia64 xm dump-core
on a paravirtualized kernel. It would seem to depend upon what, if anything,
was active at the time.
The problems here is no ramification.
xm dump-core command on ia64 or domU panic create something
with x86-dump code, however no one has verfied the resulted file
deeply yet.
Anyway in the near feature, xendump format would be revised into elf format
and its implemenation would be rewritten.
The ia64 would need to jump through the hoop of a call to
unw_init_running() before it calls HYPERVISOR_shutdown()
Is the attached patch what you want?
--
yamahata
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1166756598 -32400
# Node ID 262eb4ba1212112345018d8b94c35cb2e4fc9764
# Parent 114c8cc94466089e95bc5f78347a388c55485690
As Dave requested, call unw_init_running() before SHUTDOWN_crash.
This makes crash command happy.
PATCHNAME: unw_init_running_before_shutdown_crash
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 114c8cc94466 -r 262eb4ba1212
linux-2.6-xen-sparse/arch/ia64/kernel/setup.c
--- a/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c Thu Dec 21 17:47:31
2006 +0900
+++ b/linux-2.6-xen-sparse/arch/ia64/kernel/setup.c Fri Dec 22 12:03:18
2006 +0900
@@ -78,10 +78,17 @@ EXPORT_SYMBOL(__per_cpu_offset);
#endif
#ifdef CONFIG_XEN
+static void
+xen_panic_hypercall(struct unw_frame_info *info, void *arg)
+{
+ HYPERVISOR_shutdown(SHUTDOWN_crash);
+ /* we're never actually going to get here... */
+}
+
static int
xen_panic_event(struct notifier_block *this, unsigned long event, void *ptr)
{
- HYPERVISOR_shutdown(SHUTDOWN_crash);
+unw_init_running(xen_panic_hypercall, NULL);
/* we're never actually going to get here... */
return NOTIFY_DONE;
}
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH]remove the requirement (vpsr.ic==0) from hyperprivop
Hi, Anthony, checking your patch, I saw a call trace on booting Xen. It is attached to this e-mail. Now it became easy to understand hyperprivop codes but it seemed that the codes related to vdso should not be removed. The concrete patch that worked fine is also attached. Regards, Hiroya Xu, Anthony wrote: remove the requirement (vpsr.ic==0) from hyperprivop There are two reasons for this. 1. make xen-parse code more readable. 2. a little bit performance improvement. This patch must be applied after vcpu_get_psr fix patch. Regards, Anthony ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel Loading.: Xen Starting: Xen ELILO boot: Uncompressing Linux... |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-done Loading file initrd-2.6.16.33-xen.img-test-inakoshi...|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/done Loading file vmlinuz-2.6.16.33-xen-test-inakoshi...|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-done Uncompressing... done __ ___ ___ __ _ \ \/ /___ _ __ |___ / / _ \_ _ _ __ ___| |_ __ _| |__ | | ___ \ // _ \ '_ \|_ \| | | |__| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \ __/ | | | ___) | |_| |__| |_| | | | \__ \ || (_| | |_) | | __/ /_/\_\___|_| |_| |(_)___/\__,_|_| |_|___/\__\__,_|_.__/|_|\___| http://www.cl.cam.ac.uk/netos/xen University of Cambridge Computer Laboratory Xen version 3.0-unstable ([EMAIL PROTECTED]) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)) Fri Dec 22 13:34:31 JST 2006 Latest ChangeSet: Wed Dec 20 14:55:02 2006 -0700 13107:80c5b5914b79 (XEN) Xen command line: BOOT_IMAGE=scsi0:\EFI\xen\xen.gz-test-inakoshi com2=115200,8n1 console=com2 sched=credit tbuf_size=128 maxcpus=4 dom0_vcpus_pin (XEN) xen image pstart: 0x400, xenheap pend: 0x800 (XEN) Xen patching physical address access by offset: 0x0 (XEN) find_memory: efi_memmap_walk returns max_page=7ffed (XEN) Before xen_heap_start: f41aaa00 (XEN) After xen_heap_start: f41c (XEN) Init boot pages: 0x1c0 - 0x400. (XEN) Init boot pages: 0x800 - 0x7f708000. (XEN) Init boot pages: 0x7fe58000 - 0x7ff2. (XEN) Init boot pages: 0x18000 - 0x1fd96b000. (XEN) Init boot pages: 0x1fe7fa270 - 0x1fedf0010. (XEN) Init boot pages: 0x1fedf0070 - 0x1fedf3f4b. (XEN) Init boot pages: 0x1fedf3fcd - 0x1fedf7000. (XEN) Init boot pages: 0x1fef3bec2 - 0x1fef4c010. (XEN) Init boot pages: 0x1fef4c940 - 0x1ffe1. (XEN) Init boot pages: 0x1ffe8 - 0x1fffb4000. (XEN) System RAM: 4071MB (4168784kB) (XEN) size of virtual frame_table: 10240kB (XEN) virtual machine to physical table: f3c00098 size: 2080kB (XEN) max_page: 0x7ffed (XEN) allocating frame table/mpt table at mfn 0. (XEN) Domain heap initialised: DMA width 30 bits (XEN) Xen heap: 62MB (63744kB) (XEN) ACPI: RSDP (v002 INTEL ) @ 0x7ff72000 (XEN) ACPI: XSDT (v001 INTEL SR870BN4 0x01072002 MSFT 0x00010013) @ 0x7ff72090 (XEN) ACPI: FADT (v003 INTEL SR870BN4 0x01072002 MSFT 0x00010013) @ 0x7ff72138 (XEN) ACPI: MADT (v001 INTEL SR870BN4 0x01072002 MSFT 0x00010013) @ 0x7ff72230 (XEN) ACPI: DSDT (v001 Intel SR870BN4 0x INTL 0x20030918) @ 0x (XEN) SAL 3.20: Intel Corp SR870BN4 version 3.0 (XEN) SAL Platform features: BusLock (XEN) SAL: AP wakeup using external interrupt vector 0xf0 (XEN) cpu package is Multi-Core capable: number of cores=2 (XEN) cpu package is Multi-Threading capable: number of siblings=2 (XEN) avail:0x31700740, status:0x740,control:0x3170, vm?0x100 (XEN) WARNING: no opcode provided from hardware(0)!!! (XEN) vm buffer size: 1048576, order: 6 (XEN) cpu_init: current=f410c000 (XEN) vm_buffer: 0xf7e0 (XEN) vhpt_init: vhpt paddr=0x1fede, end=0x1fede (XEN) iosapic_system_init: Disabling PC-AT compatible 8259 interrupts (XEN) ACPI: Local APIC address e800fee0 (XEN) ACPI: LSAPIC (acpi_id[0x00] lsapic_id[0xc4] lsapic_eid[0x18] enabled) (XEN) CPU 0 (0xc418) enabled (BSP) (XEN) ACPI: LSAPIC (acpi_id[0x01] lsapic_id[0xc6] lsapic_eid[0x18] disabled) (XEN) CPU 1 (0xc618) disabled (XEN) ACPI: LSAPIC (acpi_id[0x02] lsapic_id[0xc1] lsapic_eid[0x18] enabled) (XEN) CPU 2 (0xc118) enabled (XEN) ACPI: LSAPIC
[Xen-ia64-devel] Weekly benchmark results [ww51]
Hi, I report a benchmark result of this week. semget05 seems LTP's bug (Thanks to Yamahata), so I treat it as LTP's bug. But semop05 failed now. It passed manually. Details: automatically: semop05 1 BROK : couldn't create semaphore in setup semop05 2 BROK : Remaining cases broken semop05 3 BROK : Remaining cases broken semop05 4 BROK : Remaining cases broken manually: semop05 1 PASS : expected failure - errno = 43 : Identifier removed semop05 1 PASS : expected failure - errno = 43 : Identifier removed semop05 1 PASS : expected failure - errno = 4 : Interrupted system call semop05 1 PASS : expected failure - errno = 4 : Interrupted system call TEST ENVIRONMENT Machine : Tiger4 Kernel : 2.6.16.33-xen Changeset: 13107:80c5b5914b79 (xen-ia64-unstable) Dom0 OS : RHEL4 U2 (2P) DomU OS : RHEL4 U2 (2P) # of DomU: 1 Scheduler: credit TEST RESULT unixbench4.1.0: Pass bonnie++-1.03 : Pass ltp-full-20061121 : 3/831 FAIL (see attachment) iozone3_191 : Pass lmbench-3.0-a5: Pass Best regards, KUWAMURA and Fujitsu members Test Start Time: Fri Dec 22 10:09:57 2006 - Testcase Result Exit Value -- -- abort01PASS 0 accept01 PASS 0 access01 PASS 0 access02 PASS 0 access03 PASS 0 access04 PASS 0 access05 PASS 0 acct01 PASS 0 acct02 PASS 0 adjtimex01 PASS 0 adjtimex02 PASS 0 alarm01PASS 0 alarm02PASS 0 alarm03PASS 0 alarm04PASS 0 alarm05PASS 0 alarm06PASS 0 alarm07PASS 0 asyncio02 PASS 0 bind01 PASS 0 bind02 PASS 0 brk01 PASS 0 capget01 PASS 0 capget02 PASS 0 capset01 PASS 0 capset02 PASS 0 chdir01PASS 0 chdir01A PASS 0 chdir02PASS 0 chdir03PASS 0 chdir04PASS 0 chmod01PASS 0 chmod01A PASS 0 chmod02PASS 0 chmod03PASS 0 chmod04PASS 0 chmod05PASS 0 chmod06PASS 0 chmod07PASS 0 chown01PASS 0 chown02PASS 0 chown03PASS 0 chown04PASS 0 chown05PASS 0 chroot01 PASS 0 chroot02 PASS 0 chroot03 PASS 0 chroot04 PASS 0 clone01PASS 0 clone02PASS 0 clone03PASS 0 clone04PASS 0 clone05PASS 0 clone06PASS 0 clone07PASS 0 close01PASS 0 close02PASS 0 close08PASS 0 confstr01 PASS 0 connect01 PASS 0 creat01PASS 0 creat03PASS 0 creat04PASS 0 creat05PASS 0 creat06PASS 0 creat07PASS 0 creat08PASS 0 creat09PASS 0 dup01 PASS 0 dup02 PASS 0 dup03 PASS 0 dup04 PASS 0 dup05 PASS 0 dup06 PASS 0 dup07 PASS
