similar to: how to make setting using tc command as permanent.

Hi, Can anybody tell me how to delete DSCP or TOS setting using iptable command. iptables --list OUTPUT --table mangle Chain OUTPUT (policy ACCEPT) target prot opt source destination DSCP tcp -- anywhere anywhere tcp spt:http DSCP s et 0x08 DSCP udp --

Hi all, I am wondering if anyone can help me to resolve a problem. I am trying to use tc command in linux to drop udp packets of specific diffserv value. I am able set diffserv value successfully in the udp packet using command:- [root@scotch src]#iptables --table mangle --append OUTPUT \ --out-interface eth0 --protocol udp --source-port 5060 \ --jump DSCP --set-dscp 8 but i am not able to

Hi, I have following queries: - 1.How to see data exchanged at all the bands of pfifo_fast(command)? "tc -s qdisc ls dev eth0" only shows following output qdisc pfifo_fast 0: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 71132584 bytes 312294 pkts (dropped 0, overlimits 0 requeues 0) Its only showing data exchanged in band 0. 2.I am using following command to drop

1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30) changed a bunch of btrl/btsl instructions to btr/bts, with the following justification: The inline assembly for the bit operations has been changed to remove explicit sizing hints on the instructions, so the assembler will pick the appropriate instruction forms depending on the architecture and the context. Unfortunately,

(resent without HTML) On 07/14/2013 05:56 AM, Ramkumar Ramachandra wrote: > 1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30) > changed a bunch of btrl/btsl instructions to btr/bts, with the following > justification: > > The inline assembly for the bit operations has been changed to remove > explicit sizing hints on the instructions, so the assembler will

Eli Friedman wrote: > The reason it's the right thing to do is that the mem/imm forms of > btsw and btsl have exactly the same semantics. The Intel documentation implies that this is the case: > If the bit base operand specifies a memory location, it represents the address of the byte in memory that contains the bit base (bit 0 of the specified byte) of the bit string (see Figure

On Sun, Jul 14, 2013 at 5:56 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > 1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30) > changed a bunch of btrl/btsl instructions to btr/bts, with the following > justification: > > The inline assembly for the bit operations has been changed to remove > explicit sizing hints on the instructions, so the

On Wed, Jul 10, 2013 at 7:15 PM, Jim Grosbach <grosbach at apple.com> wrote: > > On Jul 10, 2013, at 6:54 PM, Stephen Checkoway <s at pahtak.org> wrote: > > On Jul 10, 2013, at 17:44, Jim Grosbach <grosbach at apple.com> wrote: > > The length specifier is, as I understand it, required when the instruction > references memory but is optional (and inferred from

Stephen Checkoway wrote: > [...] Thanks for the absolutely splendid analysis! > For the memory, immediate form without the suffix, it seems like the options are > 1. If the immediate value is in [0,15], use btsl/btrl since it saves a byte, otherwise error; > 2. Follow both gas's behavior and the Solaris assembler manual Jim Grosbach linked to which stated that unsuffixed

Hi, I happened to notice that linux.git uses plenty of btr and bts instructions (not btrl, btrw, btsl, btsw). For examples, see arch/x86/include/asm/bitops.h. LLVM barfs on these due to ambiguity, while GNU as is fine with them. Surely, there must be architectures where the w/l variant is unavailable? LLVM must support those architectures, no? Thanks.

Jim Grosbach wrote: > That does raise a clarifying question here. Is the code you’re interested in > using Intel or AT&T syntax? > > Also note that the question isn’t whether we should support the btr/bts > instructions. We absolutely must (and do). The question is whether we are > properly handling the un-suffixed mnemonic form of the assembly syntax. > > Perhaps you

Hi guys, I am trying to compile some files using clang + llvm and I am encountering the following error during the linking step: <inline asm>:1:2: error: ambiguous instructions require an explicit suffix (could be 'btsw', 'btsl', or 'btsq') bts $14,(%eax) Which basically does not make any sense, because I don't have the mentioned inline assembly in any

On Wed, Nov 20, 2013 at 8:55 PM, Stephen Checkoway <s at pahtak.org> wrote: > > This has come up before <https://groups.google.com/forum/#!topic/llvm-dev/vomnIQjefzA>. I don't recall if there was a resolution. > Thanks for the link, completely missed when googled the issue. I think no consensus was reached (I cannot find any commit in the repository addressing such

On Wed, Jul 10, 2013 at 11:12 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > Hi, > > I happened to notice that linux.git uses plenty of btr and bts > instructions (not btrl, btrw, btsl, btsw). For examples, see > arch/x86/include/asm/bitops.h. LLVM barfs on these due to ambiguity, > while GNU as is fine with them. Surely, there must be architectures > where

On Nov 20, 2013, at 10:04 AM, Ghitulete Razvan <razvan.ghitulete at gmail.com> wrote: > <inline asm>:1:2: error: ambiguous instructions require an explicit > suffix (could be 'btsw', 'btsl', or 'btsq') > bts $14,(%eax) This has come up before <https://groups.google.com/forum/#!topic/llvm-dev/vomnIQjefzA>. I don't recall if there was a

On Nov 20, 2013, at 4:11 PM, Ghitulete Razvan <razvan.ghitulete at gmail.com> wrote: > On Wed, Nov 20, 2013 at 8:55 PM, Stephen Checkoway <s at pahtak.org> wrote: >> >> This has come up before <https://groups.google.com/forum/#!topic/llvm-dev/vomnIQjefzA>. I don't recall if there was a resolution. >> > > Thanks for the link, completely missed

On Jul 10, 2013, at 6:54 PM, Stephen Checkoway <s at pahtak.org> wrote: > On Jul 10, 2013, at 17:44, Jim Grosbach <grosbach at apple.com> wrote: >> The length specifier is, as I understand it, required when the instruction references memory but is optional (and inferred from the registers) for the register variants. >> >> The best reference I know of for the

On Thu, Jun 16, 2016 at 11:48:27AM +0900, Sergey Senozhatsky wrote: > Hi, > > On (06/16/16 08:12), Minchan Kim wrote: > > > [ 315.146533] kasan: CONFIG_KASAN_INLINE enabled > > > [ 315.146538] kasan: GPF could be caused by NULL-ptr deref or user memory access > > > [ 315.146546] general protection fault: 0000 [#1] PREEMPT SMP KASAN > > > [

On Thu, Jun 16, 2016 at 11:48:27AM +0900, Sergey Senozhatsky wrote: > Hi, > > On (06/16/16 08:12), Minchan Kim wrote: > > > [ 315.146533] kasan: CONFIG_KASAN_INLINE enabled > > > [ 315.146538] kasan: GPF could be caused by NULL-ptr deref or user memory access > > > [ 315.146546] general protection fault: 0000 [#1] PREEMPT SMP KASAN > > > [

On 07/14/2013 12:23 PM, Jeremy Fitzhardinge wrote: > (resent without HTML) > > On 07/14/2013 05:56 AM, Ramkumar Ramachandra wrote: >> 1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30) >> changed a bunch of btrl/btsl instructions to btr/bts, with the following >> justification: >> >> The inline assembly for the bit operations has been