search for: bit_offset

I''ve noticed with xen-unstable on my quad-core x dual-thread (that''s 8 processors to xen), the boot info spewed for all the C-state/P-state stuff quickly fills the xm dmesg buffer and I lose some of the early-in-boot lines. Do we really need to know "reg.{space_id,bit_width,bit_offset,access_size, address}" and all that other info? Even if so, is there a more compact way to print it? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

..._blk.address; - g_tboot_shared->acpi_sinfo.pm1a_cnt_val = acpi_sinfo.pm1a_cnt_val; - g_tboot_shared->acpi_sinfo.pm1b_cnt_val = acpi_sinfo.pm1b_cnt_val; +#define TB_COPY_GAS(tbg, g) \ + tbg.space_id = g.space_id; \ + tbg.bit_width = g.bit_width; \ + tbg.bit_offset = g.bit_offset; \ + tbg.access_width = g.access_width; \ + tbg.address = g.address; - switch ( sleep_state ) - { - case ACPI_STATE_S3: - shutdown_type = TB_SHUTDOWN_S3; - g_tboot_shared->s3_k_wakeup_entry = - (uint32_t)bootsym_phys(wakeup_...

...locks) { + SM3Block(ctx, data, blocks, W); + data += blocks * SM3_BLOCK_LENGTH; + } + + explicit_bzero(W, sizeof(W)); + + partial = 0; + } + if (len) + memcpy(ctx->buffer + partial, data, len); +} + +void +SM3Final(u_int8_t digest[SM3_DIGEST_LENGTH], SM3_CTX *ctx) +{ + const unsigned int bit_offset = SM3_BLOCK_LENGTH - sizeof(u_int64_t); + unsigned int partial = ctx->count % SM3_BLOCK_LENGTH; + u_int32_t W[16]; + int i; + + ctx->buffer[partial++] = 0x80; + if (partial > bit_offset) { + memset(ctx->buffer + partial, 0, SM3_BLOCK_LENGTH - partial); + partial = 0; + + SM3Block(ctx...

...BLOCK_LENGTH; > + } > + > + explicit_bzero(W, sizeof(W)); > + > + partial = 0; > + } > + if (len) > + memcpy(ctx->buffer + partial, data, len); > +} > + > +void > +SM3Final(u_int8_t digest[SM3_DIGEST_LENGTH], SM3_CTX *ctx) > +{ > + const unsigned int bit_offset = SM3_BLOCK_LENGTH - sizeof(u_int64_t); > + unsigned int partial = ctx->count % SM3_BLOCK_LENGTH; > + u_int32_t W[16]; > + int i; > + > + ctx->buffer[partial++] = 0x80; > + if (partial > bit_offset) { > + memset(ctx->buffer + partial, 0, SM3_BLOCK_LENGTH - partial)...

...e result. ***************************************************************************/ -static void base64_encode(char *buf, int len, char *out) +void base64_encode(char *buf, int len, char *out) { char *b64 = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"; int bit_offset, byte_offset, idx, i; diff -u rsync-2.5.6.orig/socket.c rsync-2.5.6/socket.c --- rsync-2.5.6.orig/socket.c Mon Jan 27 04:35:09 2003 +++ rsync-2.5.6/socket.c Tue May 13 13:18:55 2003 @@ -33,17 +33,56 @@ #include "rsync.h" +/** + *declare the base64_encode function from authenticate.c...

...e result. ***************************************************************************/ -static void base64_encode(char *buf, int len, char *out) +void base64_encode(char *buf, int len, char *out) { char *b64 = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"; int bit_offset, byte_offset, idx, i; diff -u rsync-2.5.5.orig/socket.c rsync-2.5.5/socket.c --- rsync-2.5.5.orig/socket.c 2002-03-16 10:00:44.000000000 +0100 +++ rsync-2.5.5/socket.c 2002-04-04 12:32:58.000000000 +0200 @@ -33,15 +33,52 @@ #include "rsync.h" +/* declare the base64_encode function fr...

Hi everyone, When I set CONFIG_ACPI_PROCESSOR, CONFIG_CPU_IDLE and CONFIG_INTEL_IDLE to y then I cannot boot Xen; there is a crash. If I turn CONFIG_INTEL_IDLE off then the boot goes well and, after dom0 has booted, xenpm works and gives some sane output, see below. I have tested this with kernels 3.2 to 3.4.6. Is it impossible to use INTEL_IDLE with Xen? If this is a known issue then maybe

Hi everyone, When I set CONFIG_ACPI_PROCESSOR, CONFIG_CPU_IDLE and CONFIG_INTEL_IDLE to y then I cannot boot Xen; there is a crash. If I turn CONFIG_INTEL_IDLE off then the boot goes well and, after dom0 has booted, xenpm works and gives some sane output, see below. I have tested this with kernels 3.2 to 3.4.6. Is it impossible to use INTEL_IDLE with Xen? If this is a known issue then maybe

...ctx->entries = entries; + return 0; +} + +int __apei_exec_read_register(struct acpi_whea_header *entry, u64 *val) +{ + int rc; + + rc = apei_read(val, &entry->register_region); + if (rc) + return rc; + *val >>= entry->register_region.bit_offset; + *val &= entry->mask; + + return 0; +} + +int apei_exec_read_register(struct apei_exec_context *ctx, + struct acpi_whea_header *entry) +{ + int rc; + u64 val = 0; + + rc = __apei_exec_read_register(entry, &val); + if (rc) +...

Hello, The following patches are a solution to a problem we have encountered when using the Xen hypervisor: - Need Pxx/Cxx states to save on power consumption when using Xen (we do want those datacenters to consume less power!), - Also need to figure out the Turbo mode so that the scheduler can properly boost a core for CPU bound guests. In essence the Xen hypervisor requires that