search for: 0x48

Hi, Since Sharps communication protocols are "top secret", I'm trying to port their sync software to linux. I'm new to wine, so this might be silly, but after hours of googling and searching for solutions I'm posting this. After installing DCOM98.exe, the Desktop software installed, and it runs. Only problem is it doesn't detect the device connected to the serial port

...ork is 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,...

...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,...

...> {IN-HARDIRQ-R} usage. [ 162.342030] swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes: [ 162.343061] (&journal->j_state_lock){+?++}, at: [<000000003b9c3e4b>] jbd2_trans_will_send_data_barrier+0x44/0xc8 [ 162.353187] {HARDIRQ-ON-W} state was registered at: [ 162.354433] lock_acquire+0x48/0x68 [ 162.358640] _raw_write_lock+0x3c/0x50 [ 162.360716] ext4_init_journal_params.isra.6+0x40/0xa0 [ 162.363445] ext4_fill_super+0x25cc/0x2e88 [ 162.364481] mount_bdev+0x19c/0x1d8 [ 162.365345] ext4_mount+0x14/0x20 [ 162.366130] mount_fs+0x34/0x160 [ 162.366790] vfs_kern_moun...

...> {IN-HARDIRQ-R} usage. [ 162.342030] swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes: [ 162.343061] (&journal->j_state_lock){+?++}, at: [<000000003b9c3e4b>] jbd2_trans_will_send_data_barrier+0x44/0xc8 [ 162.353187] {HARDIRQ-ON-W} state was registered at: [ 162.354433] lock_acquire+0x48/0x68 [ 162.358640] _raw_write_lock+0x3c/0x50 [ 162.360716] ext4_init_journal_params.isra.6+0x40/0xa0 [ 162.363445] ext4_fill_super+0x25cc/0x2e88 [ 162.364481] mount_bdev+0x19c/0x1d8 [ 162.365345] ext4_mount+0x14/0x20 [ 162.366130] mount_fs+0x34/0x160 [ 162.366790] vfs_kern_moun...

...b6677988, rc=0xb667798c) at channel.c:3524 #9 0xb78ddd29 in ast_bridge_call (chan=0xb6b26dc0, peer=0x8699fe8, config=0xb6677eb0) at res_features.c:1319 #10 0xb7033301 in dial_exec_full (chan=0xb6b26dc0, data=0xb6677eb0, peerflags=0xb6678568) at app_dial.c:1577 #11 0xb7031dc5 in dial_exec (chan=0x48, data=0x48) at app_dial.c:1619 #12 0x0808e445 in pbx_extension_helper (c=0xb6b26dc0, con=0x48, context=0xb6b26f10 "op05_x", exten=0xb6b27004 "00116", priority=1, label=0x0, callerid=0x0, action=0) at pbx.c:553 #13 0x0808efea in __ast_pbx_run (c=0xb6b26dc0) at pbx.c:2227 #14...

...usage. > [ 162.342030] swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes: > [ 162.343061] (&journal->j_state_lock){+?++}, at: [<000000003b9c3e4b>] jbd2_trans_will_send_data_barrier+0x44/0xc8 > [ 162.353187] {HARDIRQ-ON-W} state was registered at: > [ 162.354433] lock_acquire+0x48/0x68 > [ 162.358640] _raw_write_lock+0x3c/0x50 > [ 162.360716] ext4_init_journal_params.isra.6+0x40/0xa0 > [ 162.363445] ext4_fill_super+0x25cc/0x2e88 > [ 162.364481] mount_bdev+0x19c/0x1d8 > [ 162.365345] ext4_mount+0x14/0x20 > [ 162.366130] mount_fs+0x34/0x160...

...ALTERNATE_STORAGE flag set: root at dovecot:/srv/dovecot/mail/ mav.com.br/daniel.colchete/mailboxes/INBOX/dbox-Mails# doveadm dump dovecot.index|grep RECORD|head -- RECORDS: 932 RECORD: seq=1, uid=9393, flags=0x49 (Seen Answered) RECORD: seq=2, uid=9442, flags=0x40 RECORD: seq=3, uid=10253, flags=0x48 (Seen) RECORD: seq=4, uid=10268, flags=0x48 (Seen) RECORD: seq=5, uid=10283, flags=0x48 (Seen) RECORD: seq=6, uid=10309, flags=0x48 (Seen) RECORD: seq=7, uid=10311, flags=0x40 RECORD: seq=8, uid=10324, flags=0x49 (Seen Answered) RECORD: seq=9, uid=10330, flags=0x48 (Seen) Thank you very much. Bes...

...%[re]ax > -# ifdef CONFIG_X86_64 > .mmu_write_cr3 = { 0x0f, 0x22, 0xdf }, // mov %rdi, %cr3 > .irq_restore_fl = { 0x57, 0x9d }, // push %rdi; popfq > .cpu_wbinvd = { 0x0f, 0x09 }, // wbinvd > @@ -50,19 +45,11 @@ static const struct patch_xxl patch_data_xxl = { > 0x48, 0x0f, 0x07 }, // swapgs; sysretq > .cpu_swapgs = { 0x0f, 0x01, 0xf8 }, // swapgs > .mov64 = { 0x48, 0x89, 0xf8 }, // mov %rdi, %rax > -# else > - .mmu_write_cr3 = { 0x0f, 0x22, 0xd8 }, // mov %eax, %cr3 > - .irq_restore_fl = { 0x50, 0x9d }, // push %eax; popf > - .cpu_ir...

...%[re]ax > -# ifdef CONFIG_X86_64 > .mmu_write_cr3 = { 0x0f, 0x22, 0xdf }, // mov %rdi, %cr3 > .irq_restore_fl = { 0x57, 0x9d }, // push %rdi; popfq > .cpu_wbinvd = { 0x0f, 0x09 }, // wbinvd > @@ -50,19 +45,11 @@ static const struct patch_xxl patch_data_xxl = { > 0x48, 0x0f, 0x07 }, // swapgs; sysretq > .cpu_swapgs = { 0x0f, 0x01, 0xf8 }, // swapgs > .mov64 = { 0x48, 0x89, 0xf8 }, // mov %rdi, %rax > -# else > - .mmu_write_cr3 = { 0x0f, 0x22, 0xd8 }, // mov %eax, %cr3 > - .irq_restore_fl = { 0x50, 0x9d }, // push %eax; popf > - .cpu_ir...

...ecot/mail/ >> mav.com.br/daniel.colchete/mailboxes/INBOX/dbox-Mails# doveadm dump >> dovecot.index|grep RECORD|head >> -- RECORDS: 932 >> RECORD: seq=1, uid=9393, flags=0x49 (Seen Answered) >> RECORD: seq=2, uid=9442, flags=0x40 >> RECORD: seq=3, uid=10253, flags=0x48 (Seen) >> RECORD: seq=4, uid=10268, flags=0x48 (Seen) >> RECORD: seq=5, uid=10283, flags=0x48 (Seen) >> RECORD: seq=6, uid=10309, flags=0x48 (Seen) >> RECORD: seq=7, uid=10311, flags=0x40 >> RECORD: seq=8, uid=10324, flags=0x49 (Seen Answered) >> RECORD: seq=9, u...

Dear mailinglist, I own a Gigabyte motherboard GA 970A UD3 with IOMMU support. Since the update XSA-36 (also part of the latest debian wheezy pkg), the IO-Virtualisation does not work any more as discussed on this mailinglist [0] and [1]. I like to ask, if there is an "official" solution in sight. I''m not sure about my alternatives. How "dangerous" is the

...ype 0x2 id 0x10 flags 0x0 (XEN) AMD-Vi: IVHD Device Entry: type 0x3 id 0x100 flags 0x0 (XEN) AMD-Vi: Dev_Id Range: 0x100 -> 0x101 (XEN) AMD-Vi: IVHD Device Entry: type 0x2 id 0x38 flags 0x0 (XEN) AMD-Vi: IVHD Device Entry: type 0x2 id 0x200 flags 0x0 (XEN) AMD-Vi: IVHD Device Entry: type 0x2 id 0x48 flags 0x0 (XEN) AMD-Vi: IVHD Device Entry: type 0x2 id 0x300 flags 0x0 (XEN) AMD-Vi: IVHD Device Entry: type 0x2 id 0x88 flags 0x0 (XEN) AMD-Vi: IVHD Device Entry: type 0x3 id 0x90 flags 0x0 (XEN) AMD-Vi: Dev_Id Range: 0x90 -> 0x92 (XEN) AMD-Vi: IVHD Device Entry: type 0x3 id 0x98 flags 0x0 (XE...

...R4: 00000000003406e0 [ 56.593200] Call Trace: [ 56.593252] ? nvkm_pmu_reset+0x94/0x160 [nouveau] [ 56.593268] nvkm_pmu_preinit+0x12/0x20 [nouveau] [ 56.593276] nvkm_subdev_preinit+0x34/0x120 [nouveau] [ 56.593291] nvkm_device_init+0x60/0x270 [nouveau] [ 56.593305] nvkm_udevice_init+0x48/0x60 [nouveau] [ 56.593313] nvkm_object_init+0x40/0x190 [nouveau] [ 56.593320] nvkm_object_init+0x80/0x190 [nouveau] [ 56.593328] nvkm_client_init+0xe/0x10 [nouveau] [ 56.593343] nvkm_client_resume+0xe/0x10 [nouveau] [ 56.593350] nvif_client_resume+0x14/0x20 [nouveau] [ 56.593365]...

...etween two xen boxes running libvirt 1.2.12, However i seem to be getting the following error root@libvirt-xen1:~# virsh migrate --live trusty-image qemu+ssh://192.168.13.9/system --copy-storage-all --verbose --persistent --undefinesource root@192.168.13.9's password: error: unsupported flags (0x48) in function libxlDomainMigrateBegin3Params root@libvirt-xen1:~# virsh migrate --live trusty-image xen+ssh://192.168.13.9/system --copy-storage-all --verbose --persistent --undefinesource root@192.168.13.9's password: error: unsupported flags (0x48) in function libxlDomainMigrateBegin3Params...

...nnected (normal left inverted right x axis y axis) LVDS-1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1280x1024 59.9*+ 1400x1050 60.0 + 60.0 1280x960 59.9 1152x864 60.0 1024x768 59.9 800x600 59.9 640x480 59.4 720x400 59.6 640x400 60.0 640x350 59.8 === SYS/SYSFS === $ cat /sys/bus/i2c/devices/1-0075/name ch7006 $ cat /sys/bus/i2c/devices/i2c-0/name nouveau-0000:01:00.0-0 $ cat /sys/bus/i2c/devices/i2c-1/name nouveau-0000:01:00.0-1 $ cat /sys/bus/...

...x[i] = sinf(x[i]); } Which I compiled with: clang++ -O3 -march=native -mtune=native -c -o vec.o vec.cc -lmvec -fno-math-errno And here is what I get: vec.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 <_Z4fct1Dv4_f>: 0: 48 83 ec 48 sub $0x48,%rsp 4: c5 f8 29 04 24 vmovaps %xmm0,(%rsp) 9: e8 00 00 00 00 callq e <_Z4fct1Dv4_f+0xe> e: c5 f8 29 44 24 30 vmovaps %xmm0,0x30(%rsp) 14: c5 fa 16 04 24 vmovshdup (%rsp),%xmm0 19: e8 00 00 00 00 callq 1e <_Z4fct1Dv4_f+0x1e> 1e: c5 f8 29 4...

...that bindkey statement (I have never used the search backwards function). Is this a change in tcsh? Has something changed in the X server? Here is the output from xev when pressing and releasing the Backspace key: KeyPress event, serial 28, synthetic NO, window 0x2800001, root 0x48, subw 0x0, time 1593248, (136,112), root:(179,193), state 0x0, keycode 22 (keysym 0xff08, BackSpace), same_screen YES, XLookupString gives 1 bytes: (08) " XmbLookupString gives 1 bytes: (08) " XFilterEvent returns: False KeyRelease event, serial 28, synth...

...*/ ireg.eax.b[1] = 0x41; ireg.ebx.w[0] = 0x55aa; - ireg.eflags.b[0] = 0x3; /* CF set */ + ireg.edx.b[0] = devno; __intcall(0x13,&ireg,&oreg); @@ -353,6 +353,7 @@ struct disk *bios_disk_init(void *privat edd_params.len = sizeof edd_params; ireg.eax.b[1] = 0x48; + ireg.edx.b[0] = devno; ireg.ds = SEG(&edd_params); ireg.esi.w[0] = OFFS(&edd_params); __intcall(0x13,&ireg,&oreg);

> On Tue, Apr 01, 2014 at 02:53:02PM -0400, Ilia Mirkin wrote: >I believe that ch7006 is the only external encoder that's supposed to >work, so you're in luck. It sounds like it passes the nv04_tv_identify >stage of nv04_tv_create -- perhaps it fails later? Although based on >the prints, it's even doing dpms stuff (but it hits _detect a second >time... odd). Try