Displaying 20 results from an estimated 360 matches for "0x89".
Did you mean:
0x80
2007 Oct 11
0
2 commits - libswfdec/swfdec_as_context.c libswfdec/swfdec_initialize.as libswfdec/swfdec_initialize.h
...0x30, 0x4E, 0x96, 0x02,
+ 0x00, 0x08, 0x88, 0x9B, 0x0B, 0x00, 0x00, 0x01, 0x00, 0x73, 0x74, 0x79, 0x6C, 0x65, 0x00, 0x9D,
+ 0x03, 0x96, 0x02, 0x00, 0x08, 0x83, 0x1C, 0x96, 0x01, 0x00, 0x02, 0x49, 0x12, 0x9D, 0x02, 0x00,
+ 0x05, 0x00, 0x96, 0x01, 0x00, 0x02, 0x3E, 0x96, 0x09, 0x00, 0x08, 0x89, 0x07, 0x00, 0x00, 0x00,
+ 0x00, 0x08, 0x77, 0x40, 0x3C, 0x96, 0x02, 0x00, 0x08, 0x83, 0x1C, 0x96, 0x02, 0x00, 0x08, 0x8A,
+ 0x4E, 0x12, 0x9D, 0x02, 0x00, 0x15, 0x00, 0x96, 0x02, 0x00, 0x08, 0x89, 0x1C, 0x96, 0x04, 0x00,
+ 0x08, 0x8B, 0x08, 0x83, 0x1C, 0x96, 0x02, 0x00, 0x08, 0x8A, 0x4E...
2007 Oct 10
0
4 commits - libswfdec/Makefile.am libswfdec/swfdec_initialize.as libswfdec/swfdec_initialize.h m4/gtk-doc.m4 Makefile.am test/trace
...0x30, 0x4E,
- 0x96, 0x02, 0x00, 0x08, 0x88, 0x9B, 0x0B, 0x00, 0x00, 0x01, 0x00, 0x73, 0x74, 0x79, 0x6C, 0x65,
- 0x00, 0x9D, 0x03, 0x96, 0x02, 0x00, 0x08, 0x83, 0x1C, 0x96, 0x01, 0x00, 0x02, 0x49, 0x12, 0x9D,
- 0x02, 0x00, 0x05, 0x00, 0x96, 0x01, 0x00, 0x02, 0x3E, 0x96, 0x09, 0x00, 0x08, 0x89, 0x07, 0x00,
- 0x00, 0x00, 0x00, 0x08, 0x77, 0x40, 0x3C, 0x96, 0x02, 0x00, 0x08, 0x83, 0x1C, 0x96, 0x02, 0x00,
- 0x08, 0x8A, 0x4E, 0x12, 0x9D, 0x02, 0x00, 0x15, 0x00, 0x96, 0x02, 0x00, 0x08, 0x89, 0x1C, 0x96,
- 0x04, 0x00, 0x08, 0x8B, 0x08, 0x83, 0x1C, 0x96, 0x02, 0x00, 0x08, 0x8A, 0x4E...
2015 Mar 24
3
[LLVMdev] [PATCH] fix outs/ins of MOV16mr instruction (X86)
...et/X86/X86InstrInfo.td
@@ -1412,7 +1412,7 @@ let SchedRW = [WriteStore] in {
def MOV8mr : I<0x88, MRMDestMem, (outs), (ins i8mem :$dst, GR8 :$src),
"mov{b}\t{$src, $dst|$dst, $src}",
[(store GR8:$src, addr:$dst)], IIC_MOV_MEM>;
-def MOV16mr : I<0x89, MRMDestMem, (outs), (ins i16mem:$dst, GR16:$src),
+def MOV16mr : I<0x89, MRMDestMem, (outs i16mem:$dst), (ins GR16:$src),
"mov{w}\t{$src, $dst|$dst, $src}",
[(store GR16:$src, addr:$dst)], IIC_MOV_MEM>, OpSize16;
def MOV32mr : I<0x89, MRMDestMe...
2011 Jul 14
0
btrfs panic
...INFO: possible recursive locking detected ]
[ 1998.329940] 2.6.39+ #3
[ 1998.329940] ---------------------------------------------
[ 1998.329940] dd/25718 is trying to acquire lock:
[ 1998.329940] (&(&eb->lock)->rlock){+.+...}, at: [<ffffffffa025dbe1>] btrfs_try_spin_lock+0x2a/0x89 [btrfs]
[ 1998.329940]
[ 1998.329940] but task is already holding lock:
[ 1998.329940] (&(&eb->lock)->rlock){+.+...}, at: [<ffffffffa025dbae>] btrfs_clear_lock_blocking+0x22/0x2b [btrfs]
[ 1998.478275]
[ 1998.478275] other info that might help us debug this:
[ 1998.478275] 2...
2012 Nov 15
1
[LLVMdev] potential mach_override/mach_override.c fix
...xander Potapenko in...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289#c29
Index: mach_override.c
===================================================================
--- mach_override.c (revision 167724)
+++ mach_override.c (working copy)
@@ -725,6 +725,8 @@
{ 0x2, {0xFF, 0x00}, {0x89, 0x00} }, //
mov r/m32,r32 or r/m16,r16
{ 0x3, {0xFF, 0xFF, 0xFF}, {0x49, 0x89, 0xF8} }, //
mov %rdi,%r8
{ 0x4, {0xFF, 0xFF, 0xFF, 0xFF}, {0x40, 0x0F, 0xBE, 0xCE} }, //
movsbl %sil,%ecx
+ { 0x7, {0xFF, 0xFF, 0xFF, 0x00,...
2016 Nov 09
3
[PATCH] acpi: video: Move ACPI_VIDEO_NOTIFY_* defines to acpi/video.h
...OTIFY_NEXT_OUTPUT 0x83
-#define ACPI_VIDEO_NOTIFY_PREV_OUTPUT 0x84
-
-#define ACPI_VIDEO_NOTIFY_CYCLE_BRIGHTNESS 0x85
-#define ACPI_VIDEO_NOTIFY_INC_BRIGHTNESS 0x86
-#define ACPI_VIDEO_NOTIFY_DEC_BRIGHTNESS 0x87
-#define ACPI_VIDEO_NOTIFY_ZERO_BRIGHTNESS 0x88
-#define ACPI_VIDEO_NOTIFY_DISPLAY_OFF 0x89
#define MAX_NAME_LEN 20
diff --git a/include/acpi/video.h b/include/acpi/video.h
index 4536bd3..bfe484d 100644
--- a/include/acpi/video.h
+++ b/include/acpi/video.h
@@ -30,6 +30,17 @@ struct acpi_device;
#define ACPI_VIDEO_DISPLAY_LEGACY_PANEL 0x0110
#define ACPI_VIDEO_DISPLAY_LEGACY_TV...
2016 May 04
2
OrcLazyJIT for windows
...needed to both support linux/windows but I am not
sure how this is best dealt with in llvm.
// windows (arguments go to rcx and rdx and have reversed order)---
const uint8_t ResolverCode[] = {
// resolver_entry:
0x55, // 0x00: pushq %rbp
0x48, 0x89, 0xe5, // 0x01: movq %rsp, %rbp
0x50, // 0x04: pushq %rax
0x53, // 0x05: pushq %rbx
0x51, // 0x06: pushq %rcx
0x52,...
2017 Dec 19
1
Xen PV DomU running Kernel 4.14.5-1.el7.elrepo.x86_64: xl -v vcpu-set <domU> <val> triggers domU kernel WARNING, then domU becomes unresponsive
...> -----CentOS 6 kernel-ml-4.14.5-1.el6.elrepo.x86_64 end here-----
>
> -----CentOS 7 kernel-ml-4.14.5-1.el7.elrepo.x86_64 start here-----
> [? 116.528885] ------------[ cut here ]------------
> [? 116.528894] WARNING: CPU: 3 PID: 38 at block/blk-mq.c:1144
> __blk_mq_run_hw_queue+0x89/0xa0
> [? 116.528898] Modules linked in: intel_cstate(-) ip_set_hash_ip ip_set
> nfnetlink x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul
> ghash_clmulni_intel pcbc aesni_intel crypto_simd glue_helper cryptd
> intel_rapl_perf pcspkr nfsd auth_rpcgss nfs_acl lockd grace sunr...
2014 Mar 31
2
[LLVMdev] registerSize on X86 confused?
...insn->addressSize = (hasAdSize ? 2 : 4);
insn->displacementSize = (hasAdSize ? 2 : 4);
insn->immediateSize = (hasOpSize ? 2 : 4);
}
....
This is confused to me: so we have registerSize to be either 2 or 4 bytes.
But we might have instruction like:
adc al, 0x89
This case we should have registerSize = 1 for AL. So is this a bug, or I am
misunderstanding the meaning of this "registerSize" ??
Thank you.
Jun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/2014...
2007 Apr 18
0
[PATCH 1/12] gdt-tss-redundant
..._TSS]
c028b8cb: 66 c7 42 00 73 20 movw $0x2073,0x0(%edx)
c028b8d1: 66 89 5a 02 mov %bx,0x2(%edx)
c028b8d5: c1 cb 10 ror $0x10,%ebx
c028b8d8: 88 5a 04 mov %bl,0x4(%edx)
c028b8db: c6 42 05 89 movb $0x89,0x5(%edx)
=> ((char *)%edx)[5] = 0x89
(equivalent) ((char *)per_cpu(cpu_gdt_table, cpu)[GDT_ENTRY_TSS])[5] = 0x89
c028b8df: c6 42 06 00 movb $0x0,0x6(%edx)
c028b8e3: 88 7a 07 mov %bh,0x7(%edx)
c028b8e6: c1 cb 10 ror $0x10,...
2007 Apr 18
0
[PATCH 1/12] gdt-tss-redundant
..._TSS]
c028b8cb: 66 c7 42 00 73 20 movw $0x2073,0x0(%edx)
c028b8d1: 66 89 5a 02 mov %bx,0x2(%edx)
c028b8d5: c1 cb 10 ror $0x10,%ebx
c028b8d8: 88 5a 04 mov %bl,0x4(%edx)
c028b8db: c6 42 05 89 movb $0x89,0x5(%edx)
=> ((char *)%edx)[5] = 0x89
(equivalent) ((char *)per_cpu(cpu_gdt_table, cpu)[GDT_ENTRY_TSS])[5] = 0x89
c028b8df: c6 42 06 00 movb $0x0,0x6(%edx)
c028b8e3: 88 7a 07 mov %bh,0x7(%edx)
c028b8e6: c1 cb 10 ror $0x10,...
2007 Feb 24
1
Storage/SCSI Error on our CentOS server
...S:
Pending list:
2 FIFO_USE[0x0] SCB_CONTROL[0x64] SCB_SCSIID[0x7]
Total 1
Kernel Free SCB list: 3 1 0
Sequencer Complete DMA-inprog list:
Sequencer Complete list:
Sequencer DMA-Up and Complete list:
scsi4: FIFO0 Free, LONGJMP == 0x80ff, SCB 0x0
SEQIMODE[0x3f] SEQINTSRC[0x0] DFCNTRL[0x0]
DFSTATUS[0x89]
SG_CACHE_SHADOW[0x2] SG_STATE[0x0] DFFSXFRCTL[0x0]
SOFFCNT[0x0] MDFFSTAT[0x5] SHADDR = 0x00, SHCNT = 0x0
HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]
scsi4: FIFO1 Free, LONGJMP == 0x81d8, SCB 0x3
SEQIMODE[0x3f] SEQINTSRC[0x0] DFCNTRL[0x0]
DFSTATUS[0x89]
SG_CACHE_SHADOW[0x2] SG_STATE[0x0] DFFSXFRCTL[0x0]...
2009 Nov 14
2
[LLVMdev] Very slow performance of lli on x86
...7c, 0x7d, 0x7f },
{ 0x7c, 0x7d, 0x7e, 0x80 },
{ 0x7d, 0x7e, 0x7f, 0x81 },
{ 0x7e, 0x7f, 0x80, 0x82 },
{ 0x7f, 0x80, 0x81, 0x83 },
{ 0x80, 0x81, 0x82, 0x84 },
{ 0x81, 0x82, 0x83, 0x85 },
{ 0x82, 0x83, 0x84, 0x86 },
{ 0x83, 0x84, 0x85, 0x87 },
{ 0x84, 0x85, 0x86, 0x88 },
{ 0x85, 0x86, 0x87, 0x89 },
{ 0x86, 0x87, 0x88, 0x8a },
{ 0x87, 0x88, 0x89, 0x8b },
{ 0x88, 0x89, 0x8a, 0x8c },
{ 0x89, 0x8a, 0x8b, 0x8d },
{ 0x8a, 0x8b, 0x8c, 0x8e },
{ 0x8b, 0x8c, 0x8d, 0x8f },
{ 0x8c, 0x8d, 0x8e, 0x90 },
{ 0x8d, 0x8e, 0x8f, 0x91 },
{ 0x8e, 0x8f, 0x90, 0x92 },
{ 0x8f, 0x90, 0x91, 0x93 },
{ 0x9...
2017 Jan 17
2
[PATCH 2/2] virtio_scsi: Implement fc_host
...ianness correctly.
I was suspicious about it because they are defined as "u8 x[8]" in the
virtio_scsi_config struct. So you would need to read with
virtio_cread_bytes and pass the result to wwn_to_u64.
For example, if you have 0x500123456789abcd this would be
0x50 0x01 0x23 0x45 0x67 0x89 0xab 0cd
in virtio_scsi_config, and then virtio_cread64 would read it as a
little-endian u64, 0xcdab896745230150. Maybe your QEMU patch is also
writing things as little-endian 64-bit integers, rather than 8-element
arrays of bytes?
Paolo
> Maybe we should use u64 in struct virtio_scsi_config...
2017 Jan 17
2
[PATCH 2/2] virtio_scsi: Implement fc_host
...ianness correctly.
I was suspicious about it because they are defined as "u8 x[8]" in the
virtio_scsi_config struct. So you would need to read with
virtio_cread_bytes and pass the result to wwn_to_u64.
For example, if you have 0x500123456789abcd this would be
0x50 0x01 0x23 0x45 0x67 0x89 0xab 0cd
in virtio_scsi_config, and then virtio_cread64 would read it as a
little-endian u64, 0xcdab896745230150. Maybe your QEMU patch is also
writing things as little-endian 64-bit integers, rather than 8-element
arrays of bytes?
Paolo
> Maybe we should use u64 in struct virtio_scsi_config...
2006 Nov 07
4
Problems with LTO-3 and U320 on Centos 4.4
...kernel: SOFFCNT[0x6] MDFFSTAT[0x40] SHADDR =
0x020, SHCNT = 0xffffe0
Oct 30 22:02:13 gannet kernel: HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]
Oct 30 22:02:13 gannet kernel: scsi0: FIFO1 Free, LONGJMP == 0x8063, SCB
0x3
Oct 30 22:02:13 gannet kernel: SEQIMODE[0x3f] SEQINTSRC[0x0]
DFCNTRL[0x0] DFSTATUS[0x89]
Oct 30 22:02:13 gannet kernel: SG_CACHE_SHADOW[0x2] SG_STATE[0x0]
DFFSXFRCTL[0x0]
Oct 30 22:02:13 gannet kernel: SOFFCNT[0x6] MDFFSTAT[0x5] SHADDR = 0x00,
SHCNT = 0x0
Oct 30 22:02:13 gannet kernel: HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]
Oct 30 22:02:13 gannet kernel: LQIN: 0x8 0x0 0x0 0x3 0x0 0x1...
2016 May 04
2
OrcLazyJIT for windows
...>>
>>
>> // windows (arguments go to rcx and rdx and have reversed order)---
>>
>> const uint8_t ResolverCode[] = {
>>
>> // resolver_entry:
>>
>> 0x55, // 0x00: pushq %rbp
>>
>> 0x48, 0x89, 0xe5, // 0x01: movq %rsp, %rbp
>>
>> 0x50, // 0x04: pushq %rax
>>
>> 0x53, // 0x05: pushq %rbx
>>
>> 0x51, // 0x0...
2010 Jul 10
1
deadlock possiblity introduced by "drm/nouveau: use drm_mm in preference to custom code doing the same thing"
...i_probe+0x12/0x16
[ 2417.746781] [<ffffffff8121faaf>] pci_device_probe+0x60/0x8f
[ 2417.746784] [<ffffffff812aced7>] driver_probe_device+0xa7/0x136
[ 2417.746788] [<ffffffff812acfc2>] __driver_attach+0x5c/0x80
[ 2417.746790] [<ffffffff812ac632>] bus_for_each_dev+0x54/0x89
[ 2417.746793] [<ffffffff812acd46>] driver_attach+0x19/0x1b
[ 2417.746796] [<ffffffff812abf48>] bus_add_driver+0x183/0x2ef
[ 2417.746799] [<ffffffff812ad28f>] driver_register+0x98/0x109
[ 2417.746801] [<ffffffff8121fd1f>] __pci_register_driver+0x63/0xd3
[ 2417.746805...
2017 Dec 12
5
Xen PV DomU running Kernel 4.14.5-1.el7.elrepo.x86_64: xl -v vcpu-set <domU> <val> triggers domU kernel WARNING, then domU becomes unresponsive
...d trace fe2aaf4e723042fd ]---
-----CentOS 6 kernel-ml-4.14.5-1.el6.elrepo.x86_64 end here-----
-----CentOS 7 kernel-ml-4.14.5-1.el7.elrepo.x86_64 start here-----
[ 116.528885] ------------[ cut here ]------------
[ 116.528894] WARNING: CPU: 3 PID: 38 at block/blk-mq.c:1144
__blk_mq_run_hw_queue+0x89/0xa0
[ 116.528898] Modules linked in: intel_cstate(-) ip_set_hash_ip ip_set
nfnetlink x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel pcbc aesni_intel crypto_simd glue_helper cryptd
intel_rapl_perf pcspkr nfsd auth_rpcgss nfs_acl lockd grace sunrpc
ip_tables ext...
2009 Nov 14
0
[LLVMdev] Very slow performance of lli on x86
...7c, 0x7d, 0x7f },
{ 0x7c, 0x7d, 0x7e, 0x80 },
{ 0x7d, 0x7e, 0x7f, 0x81 },
{ 0x7e, 0x7f, 0x80, 0x82 },
{ 0x7f, 0x80, 0x81, 0x83 },
{ 0x80, 0x81, 0x82, 0x84 },
{ 0x81, 0x82, 0x83, 0x85 },
{ 0x82, 0x83, 0x84, 0x86 },
{ 0x83, 0x84, 0x85, 0x87 },
{ 0x84, 0x85, 0x86, 0x88 },
{ 0x85, 0x86, 0x87, 0x89 },
{ 0x86, 0x87, 0x88, 0x8a },
{ 0x87, 0x88, 0x89, 0x8b },
{ 0x88, 0x89, 0x8a, 0x8c },
{ 0x89, 0x8a, 0x8b, 0x8d },
{ 0x8a, 0x8b, 0x8c, 0x8e },
{ 0x8b, 0x8c, 0x8d, 0x8f },
{ 0x8c, 0x8d, 0x8e, 0x90 },
{ 0x8d, 0x8e, 0x8f, 0x91 },
{ 0x8e, 0x8f, 0x90, 0x92 },
{ 0x8f, 0x90, 0x91, 0x93 },
{ 0x9...