similar to: spandsp in 64 bit Linux on AMD64

Steven Hi, I'm unable to compile testcpuid.c with the __x86_64__ architecture (Athlon 64 processor). The messages are: /tmp/ccONleRV.s: Assembly messages: /tmp/ccONleRV.s: Error: suffix or operands invalid for 'pushf' " 'pop' " 'push' " 'popf' Is it safe to ignore this module? When I attempt to start asterisk, libspandsp.so.0 fails to load

I have just bought several Sipura SPA-841 SIP phones, and after some testing I have found out that the volume received by other parties when calling using the handset is very low. I've been able to reproduce this problem in the 3 phones I've tested so far. I've tried tweaking several configuration options but nothing I has helped so far. Has anybody else experienced this problem?

I am using Asterisk (Debian unstable packages) with an OH323 connection to my provider. Everything is working except for the generation of ringback tones when I receive inbound calls from the PSTN. My provider tells me that we're sending call progress indications and that because of this they're expecting us to generate the ringback tone. Does anybody know how to configure this in

are you giving answer()? ..o-------------------------------------------------------o.. Brian Fertig Network/Systems Engineer IT Administrator Planet Telecom, Inc. Tampa,FL Office -----Original Message----- From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Juan Jose Comellas Sent: Friday, September 30, 2005 10:32 AM To: Asterisk Users

Hi all, I'm a Theora noob and just taking a look at the theora-mmx package in hopes of making Thoggen run faster for DVD ripping. I've checked out the latest svn of the theora-mmx branch and trying to compile it on Ubuntu Dapper AMD64. I run autogen.sh, then make, and soon get the following errors: make[2]: Entering directory `/home/dlenski/theora-mmx/lib' if /bin/sh ../libtool

We intend to use Asterisk with a very large dialplan (with a lot of functionality for 3000+ users). Each user will be able to change several of his parameters in the dialplan, so we will be forced to reload the diaplan constantly. Has anybody else any previous experience with a similar installation? There are some things that we'd like to know, if anybody can help us. These are: - Is

I'm having some trouble dialing phone numbers in Argentina with Digium Zaptel cards. Does anyone have some sample configuration that works with Digium TDM04B cards in Argentina? I'm mainly referring to the /etc/zaptel.conf and /etc/asterisk/zapata.conf. I have two Zaptel cards: the first one has 1 FXS port and 3 FXO ports; the second one has 4 FXO ports. My current configuration is

I'm currently writing some code to support conferencing in Asterisk without using the Meetme application. The conference runs in its own thread and every new inbound or outbound channel that is created is passed to it. This thread runs the conference loop reading and writing frames to each channel. I'm writing this as if it were a bridge with more than two channels, and I'm not

Pavel Machek wrote: > Hi! > > >> 6) Interrupts must always be enabled when running code in userspace. >> > > I'd say this breaks userspace. > I agree. My claim is that this is not an issue in a virtual machine. What possible reason can you have to disable interrupts in userspace? Well, several. For one, the X server wants to disable

Pavel Machek wrote: > Hi! > > >> 6) Interrupts must always be enabled when running code in userspace. >> > > I'd say this breaks userspace. > I agree. My claim is that this is not an issue in a virtual machine. What possible reason can you have to disable interrupts in userspace? Well, several. For one, the X server wants to disable

Hello all, I am trying to implement intrinsics __readeflags and __writeeflags reading and writing EFLAGS register on x86. These intrinsics expand to two instructions popf and push to register for __readeflags and pushf and pop to register for __writeeflags. These instructions are not connected explicitly so I can't use patterns in .td file to match intrinsics. I tried to implement custom

I don't know enough about LLVM CodeGen to answer your questions. I'm just curious. What is the intended level of support for these intrinsics? Are they for reading ALU flags like CF, OF, etc, or for seldom changed control flags like TF and AC? Even DF is typically scratch, and could be used for an -Oz memmove lowering for example. I don't think LLVM will ever really support

Agreed, never emit pushf/popf. Sorry I never committed the patch, the cmov issue got hairy and I never got to debugging it :-) I can get back to it if there's interest! On Wed, Jul 29, 2015 at 4:12 PM, Reid Kleckner <rnk at google.com> wrote: > I remember this bug. :) IMO, LLVM should never emit pushf / popf. I'm not > sure this patch to fix it ever got committed: >

This intrinsic seems very ill-defined, apparently it can be freely reordered and does _not_ act like a compiler barrier. [1] Other than source compatibility, why would one want this intrinsic? What semantics is it supposed to give? [1] < http://connect.microsoft.com/VisualStudio/feedback/details/691456/-readeflags-intrinsic-can-be-reordered-by-the-compiler > On Tue, Dec 17, 2013 at 11:00

On 04/10/17 17:58, Josh Poimboeuf wrote: > Convert the hard-coded native patch assembly code strings to macros to > facilitate sharing common code between 32-bit and 64-bit. > > These macros will also be used by a future patch which requires the GCC > extended asm syntax of two '%' characters instead of one when specifying > a register name. > > Signed-off-by:

Convert the hard-coded native patch assembly code strings to macros to facilitate sharing common code between 32-bit and 64-bit. These macros will also be used by a future patch which requires the GCC extended asm syntax of two '%' characters instead of one when specifying a register name. Signed-off-by: Josh Poimboeuf <jpoimboe at redhat.com> ---

On Fri, Aug 07, 2020 at 10:38:23AM +0200, Juergen Gross wrote: > -# else > - const unsigned char cpu_iret[1]; > -# endif > }; > > static const struct patch_xxl patch_data_xxl = { > @@ -42,7 +38,6 @@ static const struct patch_xxl patch_data_xxl = { > .irq_save_fl = { 0x9c, 0x58 }, // pushf; pop %[re]ax > .mmu_read_cr2 = { 0x0f, 0x20, 0xd0 }, // mov %cr2,

On Fri, Aug 07, 2020 at 10:38:23AM +0200, Juergen Gross wrote: > -# else > - const unsigned char cpu_iret[1]; > -# endif > }; > > static const struct patch_xxl patch_data_xxl = { > @@ -42,7 +38,6 @@ static const struct patch_xxl patch_data_xxl = { > .irq_save_fl = { 0x9c, 0x58 }, // pushf; pop %[re]ax > .mmu_read_cr2 = { 0x0f, 0x20, 0xd0 }, // mov %cr2,

On 7/29/15 18:35, JF Bastien wrote: > Agreed, never emit pushf/popf. Sorry I never committed the patch, the > cmov issue got hairy and I never got to debugging it :-) > I can get back to it if there's interest! You've definitely got some interest here. I've been looking at your patch on http://reviews.llvm.org/D6629 and I think I'm up to speed on where it's stuck.

Hi all, Does anyone have thoughts on extending v->arch.hvm_vcpu.single_step to support pre-MTF systems, in a way that would mimic the MTF? So far I''m emulating PUSHF/POPF to hide the hypervisor''s trap flag, and eventually I''ll multiplex it down to the guest, but I''m having issues. Right now, I''m enabling X86_EFLAGS_TF in vmx_intr_assist, just like